From ipv6-bounces@ietf.org Mon Aug 01 02:08:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzTTc-0007a7-3Q; Mon, 01 Aug 2005 02:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzTTZ-0007a2-S0 for ipv6@megatron.ietf.org; Mon, 01 Aug 2005 02:08:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21535 for ; Mon, 1 Aug 2005 02:08:36 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzTzn-0005O8-HM for ipv6@ietf.org; Mon, 01 Aug 2005 02:41:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7168P100488 for ; Mon, 1 Aug 2005 09:08:25 +0300 Date: Mon, 1 Aug 2005 09:08:25 +0300 (EEST) From: Pekka Savola To: IPv6 WG In-Reply-To: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> Message-ID: References: <6.2.1.2.2.20050715113550.02ab8288@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: Re: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Fri, 15 Jul 2005, Bob Hinden wrote: > This starts a two week IPv6 working group last call on advancing: > > Title : IPv6 Node Information Queries > Author(s) : M. Crawford, B. Haberman > Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt > Pages : 14 > Date : 2005-7-14 > > to Experimental. Please send substantive comments to the IPv6 mailing list. > Editorial comments can be sent to the authors. Sorry for missing the DL by a couple of days, but here are my comments anyway. I've been very critical of the node information queries in the past, and still am, but as it's going to Experimental, I'm not as concerned. However, I think there are still a couple of very important things which need to be settled so that a) it can be used safely and b) it won't jeopardize the real use of IPv6 ICMP messages. Specifically, I'm very concerned about its use with global addresses, over the Internet. This has a potential to turn into a kitchen sink protocol, which can be used to do query anything at all from a random node. This is exactly the thing that makes want to firewall administrators filter out all ICMPv6 messages just to be sure messages like this won't be used in the systems. I don't think we want that. I have no objection to having a protocol like this used between consenting adults between link-local addresses or even global addresses if done over a single link -- but extending it (or providing extendibility) beyond that seems unwise. My suggestion how to deal with this is to: - add that a node MUST send all non-link-local node information queries with Hop Count 255; HC=255 MAY [or SHOULD] be used with other traffic as well; and - a node MUST, unless explicitly configured otherwise, discard any node information queries w/ non-link-local queries which don't have HC=255. This only breaks backward compat for node information queries sent w/ global addresses, over one hop away. I think we could live with that. It should provide a sufficiently simple security model for ensuring NIQ's won't be used inappropriately. A couple of specific comments below: substantial ----------- The mechanisms defined in this document may have wider applicability in the future (for example, name lookups in zero configuration networks, global reverse name lookups, etc.), but any use beyond debugging and diagnostic tools is left for further study and is beyond the scope of this document. ==> it seems inappropriate to mention these non-usages in this document, especially "global reverse name lookups"; I'd remove that at the very least. The Nonce should be a random or good pseudo-random value to foil spoofed replies. An implementation which allows multiple independent processes to send NI queries MAY use the Nonce value to deliver Replies to the correct process. Nonetheless, such processes MUST check the received Nonce and ignore extraneous Replies. ==> the "should" should be stronger. I suggest a MUST, because it's essential for the security. Otherwise, there needs to be much more text on not assuming the nonce provides any security. 6.1 NOOP This NI type has no defined flags and never has a Data field. A Reply to an NI NOOP Query tells the Querier that a node with the Queried Address is up and reachable, implements the Node Information protocol, and incidentally happens to reveal whether the Queried Address was an anycast address. [...] ==> The last sentence may require rewording as I guess whether it's revealed or not depends on which version of addr-arch is implemented..? This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol SHOULD have a default configuration which refuses to answer queries from global- scope [3] addresses. ==> I'd say a MUST here, instead of a SHOULD. editorial --------- the domain. Where necessary, the cases of fully-qalified and single- label names will be distinguished. ==> s/qali/quali/ If true communication security is required, IPsec [12] MUST be used. Providing the infrastructure to authenticate NI Queries and Replies may be quite difficult outside of a well-defined community. ==> this case seems a bit like an operational recommendation or something other than an implementation & interop issue, so uppercasing a MUST may be a bit inappropriate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 01 07:24:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzYPW-0002Qx-MA; Mon, 01 Aug 2005 07:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzYPT-0002QH-UO for ipv6@megatron.ietf.org; Mon, 01 Aug 2005 07:24:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01536 for ; Mon, 1 Aug 2005 07:24:41 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx3.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzYvk-0003Xy-Bt for ipv6@ietf.org; Mon, 01 Aug 2005 07:58:05 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j71BQY46006225 for ; Mon, 1 Aug 2005 23:26:34 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DzYP1-0000Bd-00 for ; Mon, 01 Aug 2005 23:24:15 +1200 Message-ID: <42EE065F.9030706@coders.net> Date: Mon, 01 Aug 2005 23:24:15 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050730 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: IETF IPv6 Mailing List References: <39C363776A4E8C4A94691D2BD9D1C9A10D4F63@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4F63@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1000/Mon Aug 1 07:28:06 2005 on dbmail-mx3.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (Sorry for being late on the replies, been busy recently :) > When a tunnel is used, there may be many L2 segments (connected by > L2 switches) with diverse MTUs separating the tunnel endpoints in what > otherwise appears as a single-hop to L3. And, the set of L2 segments > will often be different in the forward and reverse directions. Hrm, good point. Although IMHO since tunnels are things that are likely to be configured by the network admin (modulo 6to4 etc) if the admin screws it up it's their own fault. The point is to make it work "by default". We can't cover every possible eventuality of admins sabotaging their own network. However, on the flipside, maybe we should just do it symmetrically (and send packets both ways). It doubles the bandwidth, and halves the failure cases :) > I asked this earlier, but where are we at in the decision process > for native IPv6 vs tunneled? I'm not sure I understand the question. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 01 07:35:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzYZn-0005Jm-0h; Mon, 01 Aug 2005 07:35:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzYZl-0005J9-GW for ipv6@megatron.ietf.org; Mon, 01 Aug 2005 07:35:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02120 for ; Mon, 1 Aug 2005 07:35:18 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx4.orcon.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzZ61-0004Eh-C5 for ipv6@ietf.org; Mon, 01 Aug 2005 08:08:42 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx4.orcon.co.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j71BeJju006402 for ; Mon, 1 Aug 2005 23:40:19 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1DzYZe-0000D2-00 for ; Mon, 01 Aug 2005 23:35:14 +1200 Message-ID: <42EE08F2.8040907@coders.net> Date: Mon, 01 Aug 2005 23:35:14 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050730 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: ipv6@ietf.org References: <42DE90BC.3050403@nasa.gov> <20050721.080152.184461359.hirose@comm.yamaha.co.jp> <20050722.103248.35008368.hirose@comm.yamaha.co.jp> <20050722142037.40488001.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050722150942.4ad480a2.ipng@69706e6720323030352d30312d31340a.nosense.org> <017901c58eec$cbf479b0$6701a8c0@dax> <633A0947-9ABB-4870-8CF1-CAC491FC5BCC@muada.com> <42E25E62.2010805@coders.net> <17E800F8-AAFF-4B67-8CF9-42CB69038694@muada.com> <42E394B2.5020409@coders.net> <42E622A7.8040206@coders.net> <8FA56653-D119-47C2-8434-BE0D32C8182B@muada.com> <20050728150654.32354fae.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050728150654.32354fae.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1000/Mon Aug 1 07:28:06 2005 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Subject: Re: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Mark Smith wrote: > Hi Iljitsch, Perry, > > I'll admit I haven't been fully following your thread of discussion, > I've been a bit busy on some other things (another reason why I like the > simple solution - less thinking :-) ) > > Something to keep in mind for your solution. TCP announces the maximum > segment size it can receive in the SYN or SYN/ACK segments, and I'm > pretty sure these days that is derived directly from the (current) MTU > value of the interface it is going to use at the time of the 3-way > handshake. I'm pretty sure that irrespective of if PMTUD (or another > local link method) discovers a larger possible PMTU value at a later > time during the TCP connection, existing TCP connections will not be > able to "burst" up to it. The MSS option would be to the MTU of the outgoing interface[1], as always. The actual size sent will be limited to 1500 initially and will grow as the size is detected. The reason for this is that if you have this topology: Host A <-1500-> Switch <-9k-> Host B Then if Host B announces an MSS of 9k, host A will never try and send an 9k packet. Even in the case of: Host A <-9k-> Switch <-1500-> Switch <-9k-> Host B Host A will refuse to forward a packet to Host B thats 9k until it has fully probed the MTU up to 9k. MSS is what the machine is capable of "receiving", and the host is entirely capable of receiving a 9k MTU packet. It says nothing about the path MTU. The initial packets of a TCP connection (SYN/SYNACK) are all assured to be smaller than the IPv6 minimum maximum size (1280 bytes), by the time you want to send some real data you hope that you're a good way through your MTU probing. > Assuming that you're not planning to modify TCP as well, this means that > the knowledge of the "best" possible MTU that TCP can use must be known > at the time of the initial 3-way handshake. This limitation possibly > applies to other unicast or semi-unicast transport layer protocols too, > such as SCTP. I disagree. MSS only says what the maximum size you can receive is (Maximum Segment Size). It doesn't say "This is the maximum size I think I can receive, I might be able to receive larger" > > Thinking about these solutions another way, all they're really > attempting to do is to take the TCP-specific MSS mechanism, generalise > it so it can be used for all transport layer unicast connections, and > moving the mechanism to the network layer. Well kinda yeah. We're trying to determine the MTU of a neighbour, rather than the MTU of an interface. ---- [1]: Well, minus the size of the headers etc.. You know what I mean. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 01 14:22:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzevY-0007AX-Ff; Mon, 01 Aug 2005 14:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzevW-00071g-43 for ipv6@megatron.ietf.org; Mon, 01 Aug 2005 14:22:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29418 for ; Mon, 1 Aug 2005 14:22:10 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzfRo-0006TF-8a for ipv6@ietf.org; Mon, 01 Aug 2005 14:55:38 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA27751; Mon, 1 Aug 2005 11:21:40 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j71ILos26486; Mon, 1 Aug 2005 11:21:50 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 11:21:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2005 11:21:49 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4F6C@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: jumbo frame of GbE and IPv6 -- A proposal Thread-Index: AcWWi/fAa1Sg3niYRimBFW4W6l2UfgAOH8gw From: "Templin, Fred L" To: "Perry Lorier" X-OriginalArrivalTime: 01 Aug 2005 18:21:49.0922 (UTC) FILETIME=[E24B0C20:01C596C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: RE: jumbo frame of GbE and IPv6 -- A proposal X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org =20 > -----Original Message----- > From: Perry Lorier [mailto:perry@coders.net]=20 > Sent: Monday, August 01, 2005 4:24 AM > Cc: IETF IPv6 Mailing List > Subject: Re: jumbo frame of GbE and IPv6 -- A proposal >=20 > (Sorry for being late on the replies, been busy recently :) >=20 > > When a tunnel is used, there may be many L2 segments (connected by > > L2 switches) with diverse MTUs separating the tunnel=20 > endpoints in what > > otherwise appears as a single-hop to L3. And, the set of L2 segments > > will often be different in the forward and reverse directions. >=20 > Hrm, good point. Although IMHO since tunnels are things that=20 > are likely > to be configured by the network admin (modulo 6to4 etc) if the admin > screws it up it's their own fault. It might be a bit premature to discount the importance of automatic tunnels in actual deployment scenarios. > The point is to make it work "by > default". We can't cover every possible eventuality of admins > sabotaging their own network. >=20 > However, on the flipside, maybe we should just do it=20 > symmetrically (and > send packets both ways). It doubles the bandwidth, and halves the > failure cases :) >=20 > > I asked this earlier, but where are we at in the decision process > > for native IPv6 vs tunneled? >=20 > I'm not sure I understand the question. The question was intentionally vague and might not be answerable in a definitive way. At least, different inviduals would likely answer the question in very different ways if it were posed to them on a one-on-one basis. In hindsight, the question really didn't add anything to the technical discussion and might have been better were it omitted. Fred fred.l.templin@boeing.com =20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 01:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzpAq-0005qQ-0K; Tue, 02 Aug 2005 01:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzpAo-0005oY-4d for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 01:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29119 for ; Tue, 2 Aug 2005 01:18:40 -0400 (EDT) Received: from hng002.hotairnetwork.com ([65.124.51.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzphD-0002sc-8c for ipv6@ietf.org; Tue, 02 Aug 2005 01:52:12 -0400 Received: from localhost (localhost [127.0.0.1]) by hng002.hotairnetwork.com (Postfix) with ESMTP id 383886EC7B for ; Tue, 2 Aug 2005 00:18:33 -0500 (EST) Received: from hng002.hotairnetwork.com ([127.0.0.1]) by localhost (hng002.hotairnetwork.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13385-12 for ; Tue, 2 Aug 2005 00:18:23 -0500 (EST) Received: from [127.0.0.1] (adsl-065-081-068-147.sip.mco.bellsouth.net [65.81.68.147]) by hng002.hotairnetwork.com (Postfix) with ESMTP id F03806EC77 for ; Tue, 2 Aug 2005 00:18:22 -0500 (EST) Message-ID: <42EF022E.1010807@bluewavelabs.com> Date: Tue, 02 Aug 2005 01:18:38 -0400 From: Jim Harford Organization: Blue Wave Labs User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at hotairnetwork.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: draft-roberts-inband-qos-ipv6-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: harford@bluewavelabs.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi all, The subject Internet draft requests an IPv6 option codepoint to support in-band IP QoS signaling. This is in conjunction with work presently going on in TIA and the ITU. Due to scheduling conflicts, I am unable to attend the IPv6 session in Paris, but I will present the IP QoS work at the NSIS group on Friday morning. I understand that some discussions on this subject have already taken place within the IPv6 WG. Jim Harford (co-author) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 05:30:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzt6f-0002ja-IO; Tue, 02 Aug 2005 05:30:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzt6c-0002jT-Al for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 05:30:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02397 for ; Tue, 2 Aug 2005 05:30:35 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dztd2-0004qp-VK for ipv6@ietf.org; Tue, 02 Aug 2005 06:04:11 -0400 Received: from impact.jinmei.org (unknown [2001:688:ffff:4:e49b:cd88:b25e:3592]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3214415218; Tue, 2 Aug 2005 18:30:11 +0900 (JST) Date: Tue, 02 Aug 2005 18:30:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Arifumi Matsumoto In-Reply-To: <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipv6@ietf.org, fujisaki@syce.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 28 Jul 2005 17:28:57 +0900, >>>>> Arifumi Matsumoto said: >>> Case2: ULA or Global Prioritization >>> Case3: Multicast Source Address Selection >> >> For these cases, using a non default policy table could resolve the >> issue (and automatic policy distribution would help), but I personally >> think this should be rather dealt with through a clarification for the >> "default" selection rule, with the fact that site-local unicast >> addresses were deprecated and ULAs are introduced. > As you mention it, if ULA's address scope is defined like > Scope(link-local) < Scope(ULA) < Scope(Global), > the case 2 problem will be solved. > As Stig has pointed out, however, defining an appropriate > scope for ULA doesn't solve all the problems related to > ULA site, which I described below. (snip) > As for this point, we've had a related dialogue just before > the previous IETF meeting on dhcwg ML, which I paste below. > A VPN connectivity and a native IPv6 connectivity environment > can be an answer to the first question. That is, a site has a > native IPv6 connectiviy and also has a VPN connection, over the > native IPv6 line, to another site that doesn't provide transit > connectivity to a VPN-connected site. In this case, the same > problem occurs as the case 4. > In addition to this, what we believe is that ASP services like video > streaming, ip phone, security service and home appliance maintenance > will be getting into home networks and this trend has already started > to happen. > Even if each of these ASPs uses ULA, address selection problem > occurs once one of them has a peering with another site or > once one of them acquires another ULA block. My fundamental question here is why such closed networks need global IPv6 addresses (or even any IPv6 addresses) in the first place. Whether it's a VPN site or a closed ASP, doesn't it suffice to simply use private IPv4 addresses? If I were a network administrator, who is inherently conservative, I'd not take a risk of introducing possibly-unstable/immatured IPv6 equipments for purposes in which I don't need global connectivity. Even if I were to choose to use IPv6 for some reason, it seems I'd be just happy with ULAs for such purposes, and then the (revised) default address selection algorithm seems to suffice (and so we don't need the automatic configuration mechanism). I didn't understand why the default algorithm doesn't work here after re-reading the past message you attached and re-reading Stig's message. Perhaps I simply misunderstood the point - so could you provide a concrete example explaining why the default rule doesn't suffice there? BTW: I'm not necessarily against the proposal per se. I was just not convinced about the applicability of this mechanism *in practice*. So, if a majority of this wg believes we don't need convincing practical scenarios to adopt this proposal, I'll simply shut up. But if others also want such evidence, what I'd seek is: - realistic and convincing usage examples where the non default address selection rule is necessary. depending on the answers to the following points, I guess the VPN or closed ASP examples will suffice. - practical reasons why the closed network needs IPv6 to begin with. I've not been convinced on this point yet at all. - (on top of that) concrete examples showing why the (revised) default address selection rule doesn't work if we use ULAs for the closed network. (I'm probably seeking this just due to my misunderstanding.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 05:53:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztSJ-0007of-6u; Tue, 02 Aug 2005 05:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztSG-0007j6-Df for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 05:53:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03462 for ; Tue, 2 Aug 2005 05:52:57 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dztyi-0005nr-R3 for ipv6@ietf.org; Tue, 02 Aug 2005 06:26:33 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j729qlTb009825; Tue, 2 Aug 2005 11:52:47 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j729ql0i024495; Tue, 2 Aug 2005 11:52:47 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j729qgO5024494; Tue, 2 Aug 2005 11:52:42 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 2 Aug 2005 11:52:42 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20050802095242.GA24456@storhaugen.uninett.no> References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ipv6@ietf.org, Arifumi Matsumoto , fujisaki@syce.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Aug 02, 2005 at 06:30:07PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: [...] > Even if I were to choose to use IPv6 for some reason, it seems I'd be > just happy with ULAs for such purposes, and then the (revised) default > address selection algorithm seems to suffice (and so we don't need the > automatic configuration mechanism). I didn't understand why the > default algorithm doesn't work here after re-reading the past message > you attached and re-reading Stig's message. Perhaps I simply > misunderstood the point - so could you provide a concrete example > explaining why the default rule doesn't suffice there? My point is perhaps not that important, but here's what I was thinking of. Assume you are two sites are connecting to the global internet, both using ULAs with a ULA peering between them. Now, if a host is one of these sites do a DNS lookup for a host in the other site, and get both a ULA address and a "normal" global address, you will probably want to prefer both source and destination ULA addresses. However, if a host in one of these sites do a DNS lookup for some random host on the global internet and for some reason gets both ULA and "normal" global address, it should prefer the "normal" one. It might be discussed how important the latter is. The connection attempt would hopefully fail quickly. Also sites are not supposed to leak ULAs (should use split-DNS probably), this is almost bound to happen. Perhaps it's good not to require split-DNS? I have another point regarding ULAs and multicast. As discussed earlier, there is a problem with longest common prefix match prefering ULA source address for multicast. We've discussed a change saying that the "normal" global address should be prefered for global multicast. I believe for many sites using ULAs it would be natural to use ULA source address for scopes <= 5, but there are other sites where it would be natural for <= 8. With ULA peerings between different organizations and sites, it is possible that some may want ULA source for say scope <= A, while "normal" global addresses for larger scopes. What I'm trying to say is that the part of the network that uses ULA and have ULA peerings may not map to the same multicast scope in all deployments. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 06:19:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztpf-0003y7-1g; Tue, 02 Aug 2005 06:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztpc-0003ux-2b for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 06:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05398 for ; Tue, 2 Aug 2005 06:17:05 -0400 (EDT) Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuM1-00072k-Je for ipv6@ietf.org; Tue, 02 Aug 2005 06:50:41 -0400 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id j72AGaHa069734; Tue, 2 Aug 2005 19:16:37 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Tue, 02 Aug 2005 19:23:11 +0900 (JST) Message-Id: <20050802.192311.719889755.fujisaki@syce.net> To: jinmei@isl.rdc.toshiba.co.jp From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: References: <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, a@arifumi.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jinmei-san, | > Even if each of these ASPs uses ULA, address selection problem | > occurs once one of them has a peering with another site or | > once one of them acquires another ULA block. | | My fundamental question here is why such closed networks need global | IPv6 addresses (or even any IPv6 addresses) in the first place. | Whether it's a VPN site or a closed ASP, doesn't it suffice to simply | use private IPv4 addresses? If I were a network administrator, who is | inherently conservative, I'd not take a risk of introducing | possibly-unstable/immatured IPv6 equipments for purposes in which I | don't need global connectivity. There may be some reasons to use global IPv6 address in closed networks. The reasons are: there will be some possibilities to connect multiple 'closed' networks with each other, to have private connection with other gloabl IPv6 network, to avoid confliction with users ULA address, and so on. And acutually, Registries allow to use gloabl IPv6 address in closed networks, and some organizations got IPv6 gloabl address and have been using them in their closed network. So, "case 4, global and closed mixed conectivity" (http://www.nttv6.net/dass/#content_1_17) is not the artificial case, but the case we've been facing now. And I believe these kind of connectivities will increase as IPv6 deployment progresses. -- Tomohiro Fujisaki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 06:22:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztv6-0003nv-64; Tue, 02 Aug 2005 06:22:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dztv4-0003nN-95 for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 06:22:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05834 for ; Tue, 2 Aug 2005 06:22:42 -0400 (EDT) Received: from p127202.doubleroute.jp ([219.119.127.202] helo=s51.ath.cx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuRW-0007Lo-8A for ipv6@ietf.org; Tue, 02 Aug 2005 06:56:18 -0400 Received: from [86.255.27.150] (open-27-150.ietf63.ietf.org [86.255.27.150]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by s51.ath.cx (Postfix) with ESMTP id 0091670C2F; Tue, 2 Aug 2005 19:22:05 +0900 (JST) In-Reply-To: References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII Message-Id: <0C82FA31-472D-4694-A2B2-926EB73D8BA8@arifumi.net> Content-Transfer-Encoding: 7bit From: Arifumi Matsumoto Date: Tue, 2 Aug 2005 19:22:09 +0900 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.7 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, fujisaki@syce.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jinmei-san, thanks for your comments. Some replies below. > My fundamental question here is why such closed networks need global > IPv6 addresses (or even any IPv6 addresses) in the first place. > Whether it's a VPN site or a closed ASP, doesn't it suffice to simply > use private IPv4 addresses? If I were a network administrator, who is > inherently conservative, I'd not take a risk of introducing > possibly-unstable/immatured IPv6 equipments for purposes in which I > don't need global connectivity. > > Even if I were to choose to use IPv6 for some reason, it seems I'd be > just happy with ULAs for such purposes, and then the (revised) default > address selection algorithm seems to suffice (and so we don't need the > automatic configuration mechanism). I didn't understand why the > default algorithm doesn't work here after re-reading the past message > you attached and re-reading Stig's message. Perhaps I simply > misunderstood the point - so could you provide a concrete example > explaining why the default rule doesn't suffice there? > > BTW: I'm not necessarily against the proposal per se. I was just not > convinced about the applicability of this mechanism *in practice*. > So, if a majority of this wg believes we don't need convincing > practical scenarios to adopt this proposal, I'll simply shut up. > But if others also want such evidence, what I'd seek is: > > - realistic and convincing usage examples where the non default > address selection rule is necessary. depending on the answers to > the following points, I guess the VPN or closed ASP examples will > suffice. > - practical reasons why the closed network needs IPv6 to begin with. > I've not been convinced on this point yet at all. Do you recommend to use IPv4 addresses forever ? IPv4 private addresses has another kind of problem even for closed network, such as address collision. I guess its very common to use private address in home network, so its very likely to collide ASP's private address and that in home network. Another point is that when you start a new network service, you want to use long-life technologies and not dying ones. > - (on top of that) concrete examples showing why the (revised) default > address selection rule doesn't work if we use ULAs for the closed > network. (I'm probably seeking this just due to my > misunderstanding.) In my last e-mail, I meant that when one ASP uses more than one ULAs or has peering with another ASP(which has ULA), a consumer site cannot choose a correct source address by default address selection rule. This looks like the following. +---+ULA1 |ASP| +---+ | | ULA2 ULA3 +---+ +---+ |ASP| |ASP| +---+ +---+ | | --------- | +---+ |GW | +---+ | ----------- | +---+ | PC| +---+ As ULA is such a small address space(/48), it is very probable that an ASP has multiple ULA blocks. Additionally, at v6ops session yesterday, 6net people showed us another possible usage of address selection policy table. It's renumbering. By pouring address selection policy into each end hosts, you can easily configure address selection policy that makes end-hosts not to use old address. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories TEL: +81-422-59-3334 / FAX: +81-422-59-5652 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 06:27:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztzO-0005kH-OS; Tue, 02 Aug 2005 06:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztzL-0005iZ-81 for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 06:27:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06005 for ; Tue, 2 Aug 2005 06:27:08 -0400 (EDT) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuVn-0007WH-Ng for ipv6@ietf.org; Tue, 02 Aug 2005 07:00:44 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 12ACF5538; Tue, 2 Aug 2005 12:26:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 10352552D; Tue, 2 Aug 2005 12:26:56 +0200 (CEST) Date: Tue, 2 Aug 2005 12:26:56 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message-ID: <20050802121602.O44573@mignon.ki.iif.hu> References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-485541116-1122978416=:44573" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ipv6@ietf.org, Arifumi Matsumoto , fujisaki@syce.net Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-485541116-1122978416=:44573 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 2 Aug 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8 = wrote: >>>>>> On Thu, 28 Jul 2005 17:28:57 +0900, >>>>>> Arifumi Matsumoto said: > >>>> Case2: ULA or Global Prioritization >>>> Case3: Multicast Source Address Selection >>> >>> For these cases, using a non default policy table could resolve the >>> issue (and automatic policy distribution would help), but I personally >>> think this should be rather dealt with through a clarification for the >>> "default" selection rule, with the fact that site-local unicast >>> addresses were deprecated and ULAs are introduced. > >> As you mention it, if ULA's address scope is defined like >> Scope(link-local) < Scope(ULA) < Scope(Global), >> the case 2 problem will be solved. > >> As Stig has pointed out, however, defining an appropriate >> scope for ULA doesn't solve all the problems related to >> ULA site, which I described below. > > (snip) > >> As for this point, we've had a related dialogue just before >> the previous IETF meeting on dhcwg ML, which I paste below. > >> A VPN connectivity and a native IPv6 connectivity environment >> can be an answer to the first question. That is, a site has a >> native IPv6 connectiviy and also has a VPN connection, over the >> native IPv6 line, to another site that doesn't provide transit >> connectivity to a VPN-connected site. In this case, the same >> problem occurs as the case 4. > >> In addition to this, what we believe is that ASP services like video >> streaming, ip phone, security service and home appliance maintenance >> will be getting into home networks and this trend has already started >> to happen. >> Even if each of these ASPs uses ULA, address selection problem >> occurs once one of them has a peering with another site or >> once one of them acquires another ULA block. > > My fundamental question here is why such closed networks need global > IPv6 addresses (or even any IPv6 addresses) in the first place. > Whether it's a VPN site or a closed ASP, doesn't it suffice to simply > use private IPv4 addresses? If I were a network administrator, who is > inherently conservative, I'd not take a risk of introducing > possibly-unstable/immatured IPv6 equipments for purposes in which I > don't need global connectivity. > > Even if I were to choose to use IPv6 for some reason, it seems I'd be > just happy with ULAs for such purposes, and then the (revised) default > address selection algorithm seems to suffice (and so we don't need the > automatic configuration mechanism). I didn't understand why the > default algorithm doesn't work here after re-reading the past message > you attached and re-reading Stig's message. Perhaps I simply > misunderstood the point - so could you provide a concrete example > explaining why the default rule doesn't suffice there? > > BTW: I'm not necessarily against the proposal per se. I was just not > convinced about the applicability of this mechanism *in practice*. > So, if a majority of this wg believes we don't need convincing > practical scenarios to adopt this proposal, I'll simply shut up. > But if others also want such evidence, what I'd seek is: > > - realistic and convincing usage examples where the non default > address selection rule is necessary. depending on the answers to > the following points, I guess the VPN or closed ASP examples will > suffice. > - practical reasons why the closed network needs IPv6 to begin with. > I've not been convinced on this point yet at all. Currently we are facing an interesting problem that might justify the need= =20 for this: We have closed network that is using private IPv4 address. We are=20 expanding this network, but we run out of adjacent IPv4 addresses. We can= =20 decide: - renumber our closed network with other private IPv4 address space - introduce IPv6 addresses. Currently we are discussing internally the trade-offs the two options. So we are not starting with IPv6, but considering replacing IPv4 are least= =20 partially. What do you think of it? Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > - (on top of that) concrete examples showing why the (revised) default > address selection rule doesn't work if we use ULAs for the closed > network. (I'm probably seeking this just due to my > misunderstanding.) > > =09=09=09=09=09JINMEI, Tatuya > =09=09=09=09=09Communication Platform Lab. > =09=09=09=09=09Corporate R&D Center, Toshiba Corp. > =09=09=09=09=09jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0-485541116-1122978416=:44573 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-485541116-1122978416=:44573-- From ipv6-bounces@ietf.org Tue Aug 02 09:10:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwWt-00077f-Lp; Tue, 02 Aug 2005 09:09:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwWq-00077a-Lk for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 09:09:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17507 for ; Tue, 2 Aug 2005 09:09:54 -0400 (EDT) From: elwynd@dial.pipex.com Received: from nmail1.systems.pipex.net ([62.241.160.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzx3J-00078y-L2 for ipv6@ietf.org; Tue, 02 Aug 2005 09:43:31 -0400 Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id j72D9eVr003878; Tue, 2 Aug 2005 14:09:40 +0100 Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id j72D9dch003877; Tue, 2 Aug 2005 14:09:39 +0100 Received: from 86.255.30.238 ( [86.255.30.238]) as user elwynd@dial.pipex.com by netmail.pipex.net with HTTP; Tue, 2 Aug 2005 14:09:39 +0100 Message-ID: <1122988179.42ef709377d05@netmail.pipex.net> Date: Tue, 2 Aug 2005 14:09:39 +0100 To: Bob Hinden References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 86.255.30.238 X-PIPEX-Username: elwynd%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nmail1.systems.pipex.net id j72D9eVr003878 X-Spam-Score: 2.3 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: Proposed IPv6 W.G. Agenda for Paris - IPv6 Full Standard thoughts X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In the course of doing the security overview draft in v6ops, we identifie= d a number of issues that appear to be errata or issues with the main IPv6 st= andard. These should potentially be fixed up as 2460 goes to full standard: Points for full standard; =95 (non-)Processing of Type 0 routing headers in hosts =95 (non-)Processing of Type 2 routing headers in routers =95 Processing Extension Headers in Middleboxes -=20 o words about where headers are inpected need to be relaxed o words about processing headers out of order need to be relaxed o should intermediate nodes be allowed to discard packets with unknown= =20 extension headers? =95 Requiring that new extension headers use TLV format (and maybe puttin= g the length into the fragmentation header) - to simplify skipping headers in m= iddleboxes =95 Constraining new hop-by-hop options both as to number and function - = h-by-h should be designed either for simple fast path processing (like jumbo pac= kets) or to explicitly cause a packet to be dumped to the slow path (like route= r alert). =95 Fragment reassembly algorithm - should explicitly forbid overlapped f= ragments and possibly require that non-final fragments are (say) at least 1024 byt= es. =20 Regards, Elwyn Quoting Bob Hinden : > Here is the first cut at an agenda for the IPv6 working group session a= t=20 > the Paris IETF. Please review and send us comments, deletions, and > additions. >=20 > Thanks, > Bob Hinden & Brian Haberman > IPv6 Chairs >=20 >=20 > Internet Protocol Version 6 WG (IPv6) > Tuesday, August 2, 2005 > 1400-1600 Afternoon Session I > -------------------------------------- >=20 > Introduction, Call for Scribes, Hinden 05 minutes > and Agenda Bashing >=20 > Document Status Haberman 05 minutes >=20 > IPv6 Node Information Queries Haberman 10 minutes > Goal: Close open issues > draft-ietf-ipngwg-icmp-name-lookups-12.txt >=20 > IPv6 Address Allocation to End Sites Narten 20 minutes > Goal: Discussion > draft-narten-ipv6-3177bis-48boundary-00.txt >=20 > IPv6 over IEEE802.16 Kim 10 minutes > Goal: New draft, Initial Discussion > draft-jin-ipv6-over-ieee802.16-00.txt >=20 > URI Syntax Fenner 15 minutes > Goal: Make decision to adopt proposal > draft-fenner-literal-zone-01.txt >=20 > Implementation Reports for Haberman 10 minutes > Privacy Extensions for Stateless Address > Autoconfiguration in IPv6 > Goal: Call for reports >=20 > Next Steps for IPv6 w.g. Hinden 15 minutes > Advancing core specification to Standard > Goal: Discussion >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 09:41:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1J-0008G5-Vb; Tue, 02 Aug 2005 09:41:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx1I-0008Fz-0x for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 09:41:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19303 for ; Tue, 2 Aug 2005 09:41:21 -0400 (EDT) Message-Id: <200508021341.JAA19303@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxXl-0008Ux-88 for ipv6@ietf.org; Tue, 02 Aug 2005 10:14:58 -0400 Received: from eaglet (127.0.0.1:2555) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 2 Aug 2005 06:41:03 -0700 From: "Tony Hain" To: Date: Tue, 2 Aug 2005 15:41:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWXZ9KK3y+4QwnsThuc/CyBUdF9qA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: M & O bit discussion today X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I choose not to try to get to the mic, but on the debated requirement point 3; why is there a belief that the DHCP relay information is correctly configured if the simpler set of 2 bits is improperly configured? I agree that point 1 & 3 are in direct conflict and that 1 is the real requirement. Hosts should never try to outguess the specific instructions from the router... This means that even the case of M & O clear without a prefix should not result in a DHCP request. This only invites rouge DHCP servers as a DOS attack. One valid case for M & O clear without a prefix would be a router retracting the delegated prefix when the link associated with that prefix fails. When all such upstream links fail there should be no prefix unless the network manager has configured a ULA prefix. The lack of a prefix is not a configuration error, and hosts should not go off randomly doing something they have been instructed not to do. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 09:55:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxF5-0005u4-He; Tue, 02 Aug 2005 09:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxF3-0005sY-Qb for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 09:55:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20097 for ; Tue, 2 Aug 2005 09:55:35 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxlX-0000h5-DH for ipv6@ietf.org; Tue, 02 Aug 2005 10:29:12 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j72DtDD06802 for ; Tue, 2 Aug 2005 15:55:13 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j72DtDlp012068 for ; Tue, 2 Aug 2005 15:55:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508021355.j72DtDlp012068@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipv6@ietf.org Date: Tue, 02 Aug 2005 15:55:13 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Network discovery is a well known unsolved problem in IPv6. I believe the issue was described by Jean-Luc Richier at least 8 years ago... The previous proposed solution is based in ICMP info lookups: 1- routers' MIB are read to find next hops 2- link-local addresses of next hops are translated to usuable global addresses using an ICMP info lookup proxy service 3- goto 1 Francis.Dupont@enst-bretagne.fr PS: BTW the proxy service uses ICMP on the link, cf security considerations of ICMP infos, discussion about draft-ietf-ipngwg-icmp-name-lookups-12.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 09:59:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxIo-0006O2-Cg; Tue, 02 Aug 2005 09:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxIm-0006Nu-CP for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 09:59:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20358 for ; Tue, 2 Aug 2005 09:59:26 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxpG-0000rm-VE for ipv6@ietf.org; Tue, 02 Aug 2005 10:33:03 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j72DxIV10331; Tue, 2 Aug 2005 16:59:18 +0300 Date: Tue, 2 Aug 2005 16:59:17 +0300 (EEST) From: Pekka Savola To: Francis Dupont In-Reply-To: <200508021355.j72DtDlp012068@givry.rennes.enst-bretagne.fr> Message-ID: References: <200508021355.j72DtDlp012068@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipv6@ietf.org Subject: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 2 Aug 2005, Francis Dupont wrote: > Network discovery is a well known unsolved problem in IPv6. Isn't that a good thing, so it can't be used for mapping the network? In this case, the "cure" appears worse than the disease. My own first idea of the solution for this problem would be defining an appropriately-scoped multicast address(es) to which you'd send an echo request to. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 10:09:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxSP-0004b3-Sv; Tue, 02 Aug 2005 10:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxSN-0004Um-Q9 for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 10:09:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21286 for ; Tue, 2 Aug 2005 10:09:21 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzxyr-0001JL-FY for ipv6@ietf.org; Tue, 02 Aug 2005 10:42:58 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j72E94D07869; Tue, 2 Aug 2005 16:09:04 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j72E94DM012117; Tue, 2 Aug 2005 16:09:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508021409.j72E94DM012117@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola In-reply-to: Your message of Tue, 02 Aug 2005 16:59:17 +0300. Date: Tue, 02 Aug 2005 16:09:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: On Tue, 2 Aug 2005, Francis Dupont wrote: > Network discovery is a well known unsolved problem in IPv6. Isn't that a good thing, so it can't be used for mapping the network? => perhaps but don't forget you can't map your own network (:-). In this case, the "cure" appears worse than the disease. => the cure needs access to some services (SNMP and ICMP name lookup proxy services) which are supposed to be protected even by the stupid manager (in fact, they are by default closed). My own first idea of the solution for this problem would be defining an appropriately-scoped multicast address(es) to which you'd send an echo request to. => do we want network discovery (so it is enough to get routers and their route tables) or node discovery (in this case multicasted echo requests are necessary)? Regards Francis.Dupont@enst-bretagne.fr PS: note both proposals are based on ICMP name lookups in order to get rid of the basic issue: link-local addresses are not useful when you are not on the link. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 10:33:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxpL-0004hC-PF; Tue, 02 Aug 2005 10:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxpJ-0004gr-Bv for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 10:33:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24225 for ; Tue, 2 Aug 2005 10:33:03 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzyLn-0002c8-7Y for ipv6@ietf.org; Tue, 02 Aug 2005 11:06:40 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j72EWra11052; Tue, 2 Aug 2005 17:32:53 +0300 Date: Tue, 2 Aug 2005 17:32:53 +0300 (EEST) From: Pekka Savola To: Francis Dupont In-Reply-To: <200508021409.j72E94DM012117@givry.rennes.enst-bretagne.fr> Message-ID: References: <200508021409.j72E94DM012117@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org Subject: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, 2 Aug 2005, Francis Dupont wrote: > My own first idea of the solution for this problem would be defining > an appropriately-scoped multicast address(es) to which you'd send an > echo request to. > > => do we want network discovery (so it is enough to get routers and > their route tables) or node discovery (in this case multicasted echo > requests are necessary)? Either way is fine with me; either have the routers, the hosts, or both join the multicast group. > PS: note both proposals are based on ICMP name lookups in order to > get rid of the basic issue: link-local addresses are not useful when > you are not on the link. Sure, and this problem wouldn't exist with the multicast approach, as the source address that the hosts would pick in the responses would be global/ULA. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 10:38:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxur-00035I-SR; Tue, 02 Aug 2005 10:38:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxup-00034Z-Jn for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 10:38:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24758 for ; Tue, 2 Aug 2005 10:38:45 -0400 (EDT) Received: from srv0010.pine.nl ([213.156.9.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzyRJ-0002rX-Bd for ipv6@ietf.org; Tue, 02 Aug 2005 11:12:22 -0400 Received: from localhost (localhost [127.0.0.1]) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id 0655F435B75 for ; Tue, 2 Aug 2005 16:38:15 +0200 (CEST) Received: from srv0010.pine.nl ([127.0.0.1]) by localhost (srv0010.pine.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06690-01-54 for ; Tue, 2 Aug 2005 16:38:00 +0200 (CEST) Received: from [86.255.25.105] (open-25-105.ietf63.ietf.org [86.255.25.105]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id 00F15435A2B for ; Tue, 2 Aug 2005 16:37:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <45D51991-6E9B-49F4-8363-337022B7779A@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF IPv6 Mailing List From: Iljitsch van Beijnum Date: Tue, 2 Aug 2005 16:38:00 +0200 X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-new at pine.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Subject: remarks X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org My remarks in the session just now: IIRC, 24 bits of the address are encoded in the solicited node address, good luck finding hardware that can handle this many multicast groups. I still would like to know what exactly requirement 3 would be: - still DHCPv6 if routers send the default 00 MO bits, or - "requirement" to do DHCPv6 always regardless what routers say (Note that all I care about / anyone here should care about is out of the box behavior, if people configure their hosts to play the French national anthem when the O bit is set, which is clearly not mandated by any RFC, they can always do that. Vendors just shouldn't make it happen by default.) The question: are there now implementations that do something different when the MO bits aren't 00 as opposed to when they are? I.e., what do we break by redifining these bits? All the stuff I've seen in the wild just ignores the bits. Iljitsch van Beijnum -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 10:50:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzy6L-0001gQ-Cw; Tue, 02 Aug 2005 10:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzy6J-0001gL-VM for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 10:50:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25624 for ; Tue, 2 Aug 2005 10:50:37 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzycn-0003Tq-1Y for ipv6@ietf.org; Tue, 02 Aug 2005 11:24:15 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j72Eo9D11115; Tue, 2 Aug 2005 16:50:09 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j72Eo9OT012260; Tue, 2 Aug 2005 16:50:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508021450.j72Eo9OT012260@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola In-reply-to: Your message of Tue, 02 Aug 2005 17:32:53 +0300. Date: Tue, 02 Aug 2005 16:50:09 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: > PS: note both proposals are based on ICMP name lookups in order to > get rid of the basic issue: link-local addresses are not useful when > you are not on the link. Sure, and this problem wouldn't exist with the multicast approach, as the source address that the hosts would pick in the responses would be global/ULA. => I disagree: the problem still exists but in a different form: to make a network map/topology you need to bind link-local and global addresses. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 11:04:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyK4-0006rD-Mt; Tue, 02 Aug 2005 11:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyK3-0006r8-2X for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 11:04:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26759 for ; Tue, 2 Aug 2005 11:04:48 -0400 (EDT) Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzyqW-0004D9-Jw for ipv6@ietf.org; Tue, 02 Aug 2005 11:38:26 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j72F4aa15386; Tue, 2 Aug 2005 17:04:36 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp450.cisco.com [10.61.65.194]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j72F4Zp23378; Tue, 2 Aug 2005 17:04:36 +0200 (CEST) Message-Id: <4.3.2.7.2.20050802165919.033d8480@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Aug 2005 17:04:34 +0200 To: Francis Dupont From: "Gunter Van de Velde (gvandeve)" In-Reply-To: <200508021450.j72Eo9OT012260@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipv6@ietf.org, Pekka Savola Subject: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >=> I disagree: the problem still exists but in a different form: to make >a network map/topology you need to bind link-local and global addresses. Not sure. Why do you assume that the global address tells you anything about location? It would be better to have something that maps identities of devices and at his turn potentially maps it into some kind of topologies. It would be interesting however to have awareness of who is attached and with which addresses (a use example would be for ISP billing purposes). There are techniques out there that allow this to be done, but i doubt if we need a protocol for this purpose as such. Groetjes, G/ At 16:50 2/08/2005 +0200, Francis Dupont wrote: > In your previous mail you wrote: > > > PS: note both proposals are based on ICMP name lookups in order to > > get rid of the basic issue: link-local addresses are not useful when > > you are not on the link. > > Sure, and this problem wouldn't exist with the multicast approach, as > the source address that the hosts would pick in the responses would be > global/ULA. > >=> I disagree: the problem still exists but in a different form: to make >a network map/topology you need to bind link-local and global addresses. > >Regards > >Francis.Dupont@enst-bretagne.fr > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 11:16:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyV7-0002go-2M; Tue, 02 Aug 2005 11:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyV5-0002gZ-BQ for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 11:16:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27667 for ; Tue, 2 Aug 2005 11:16:12 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzz1X-0004nt-ED for ipv6@ietf.org; Tue, 02 Aug 2005 11:49:50 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IKL00MV3P2L9K@mailout1.samsung.com> for ipv6@ietf.org; Wed, 03 Aug 2005 00:15:57 +0900 (KST) Received: from samsung70c651a ([124.235.141.1]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IKL00HL3P2IKU@mmp2.samsung.com> for ipv6@ietf.org; Wed, 03 Aug 2005 00:15:57 +0900 (KST) Date: Wed, 03 Aug 2005 00:15:52 +0900 From: Soohong Daniel Park To: Tony Hain , ipv6@ietf.org Message-id: <00d301c59775$141fbfc0$5207ff56@samsung70c651a> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-RFC2646: Format=Flowed; Original References: <200508021341.JAA19303@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7BIT Cc: Subject: Re: M & O bit discussion today (Requirement 3) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org As I pointed out, all requirement doesn't have any explicit conclusion, rather just refering them to make more shape requirement. Several guys from IPv6 meeting room (and mailing list) are saying that we don't need to care about Requirement 3. Also, Requirement 1 is at least acceptable and Requirement 2 remains without any decision... 1) Ability to indicate to a host "DHCP is not available on this link", with the expectation that the host won't send any DHCP messages 2) Ability for a host to get all desired and available DHCP configuration with a single DHCP message exchange 3) Ability to do DHCP without having to configure routers (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or ICB anyway) I am asking some questions like below; 1) Which requirement is acceptable (and which is not acceptable) ? 2) Other requirements to be considered ? Regards, Daniel (Soohong Daniel Park) Mobile Platform Lab., SAMSUNG Electronics. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 11:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyXy-0004UV-Qw; Tue, 02 Aug 2005 11:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzyXw-0004Ou-F4; Tue, 02 Aug 2005 11:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27938; Tue, 2 Aug 2005 11:19:09 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzz4L-00050C-RO; Tue, 02 Aug 2005 11:52:48 -0400 Received: from impact.jinmei.org (unknown [2001:688:ffff:4:e49b:cd88:b25e:3592]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7629A15218; Wed, 3 Aug 2005 00:19:01 +0900 (JST) Date: Wed, 03 Aug 2005 00:18:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, dhcwg@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org It was unfortunate we happened to concentrate on 'requirement 3' in today's discussion...whether or not the motivation behind the 'requirement', it's definitely a minor point, compared to requirement 1 (see below). In that sense, I agree that the requirement 1 is the 'real requirement'. So, can we now concentrate on requirement 1 (see below also), rather than playing with 'requirement 3' further? If we reach consensus on requirement 1, then it will likely solve issues around requirement 3 (if any) automatically. I think the major points are: a. whether we need the 2 bits or 1 bit is just enough b. how strict we should be about the case where the flag(s) is OFF (say MUST NOT invoke DHCPv6, say SHOULD NOT invoke DHCPv6, just make informative note without RFC2119 keywords, others...?) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp >>>>> On Thu, 28 Jul 2005 01:37:48 +0900, >>>>> JINMEI Tatuya said: >> While opinions on the details so varied, we seem to have agreed that >> we need to fix the requirements for those flags (or something >> similar/replacement in RA) first. > With some minor updates after clarification discussions, here is the > latest version of the requirement list: > 1) Ability to indicate to a host "DHCP is not available on this link", > with the expectation that the host won't send any DHCP messages > 1') Some people also wanted to indicate a stronger message of "do > not try to find it" for some networks in requirement 1. > Possible scenarios include bandwidth-sensitive networks (such > as 3G?) and the case where attacks of rogue DHCPv6 messages are > concerned. > 1'') Some people (one person?) also wanted the ability to indicate > to a host "a particular type of DHCPv6 (i.e., ICB or HCB) is not > available on this link" (This is probably a combination like > M=0&&O=1 would currently indicate). > [Note: requirement 1'' can also have two variations: with or > without the intent of "do not try to find it". But since the "some > people" seem to be the same group, there is probably no version of > 1'' without the intent] > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > - if a host wants HCB, it sends an HCB request (Solicit) and receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request (Information-request) > and receives ICB replies > 3) Ability to do DHCP without having to configure routers > (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or > ICB anyway) > [Note: this requirement may contradict requirement 1'. We'll need > to determine which one should be honored or whether there is an > intermediate compromise.] > Terminology: > HCB: getting address (and possible other) configuration information > by Solicit/Advertise/Request/Reply exchanges > ICB: getting other configuration than addresses (excluding > addresses) by Information-request/Reply exchanges > I hope the above summary correctly covers major points we've seen. > Now, at the risk of causing another cycle of opinion storm, the > followings are related notes on each point from the past discussion. > (I'm trying to be just an editor aside from my own opinion, but, of > course, I cannot 100% escape from that) > Requirement 2 seems least controversial. In my understanding, this is > basically for removing redundant probe packets or hopeless timeouts > for unavailable service. In particular, we wanted to avoid scenario > where an HCB client continues sending Solicits even if there is no HCB > server but an ICB-only server, and even if the client can somehow > benefit from the "ICB part" excluding addresses. Such a case is most > likely a result from temporary dead servers or configuration errors, > but we seem to have agreed that we want to deal with such cases. > Requirement 2 can be met through some extensions to RFC3315 and > RFC3736. The obvious question is whether we can accept such extensions > in terms of standardization and compatibility with existing > implementations. In particular, some people expressed concern about > requiring changes to ICB-only (RFC3736) server implementations. In > general, however, my understanding is that people were positive about > upgrading the DHCPv6 specifications, considering the > specification/implementation maturity. > Requirement 1 generally comes from some types of networks such as > cellular networks where network bandwidth or buttery consumption of > end stations is sensitive issues. I think people generally understood > the point and agreed that the appropriate mechanism for implementing > this is flag(s) in RAs. > However, opinions on the details appeared to vary, causing lots of > confusion. The major controversial points are probably summarized in > the succeeding sub-requirements: > - whether we need to prohibit the use of DHCPv6 more strongly and > explicitly (e.g., with a 'MUST NOT'), which corresponds to > Requirement 1'. > I know there is a strong opinion for this requirement, but I'm not > sure if that was a majority. On the other hand, if we adopt this > requirement with the strongest wording such as 'MUST NOT', it will > contradict with Requirement 3 (if we agree that it has some valid > points). Additionally, as we briefly talked very recently, such > strongest text would also break our general agreement that the RA > flag(s) are just a trigger without containing mandatory > requirements. > We'll probably need to seek some middle ground by, e.g., wording > compromise. I don't have a specific idea about how to do that > right now, though. > - whether we need to separate the 'ability' for HCB and ICB, which > corresponds to Requirement 1''. > If we need to separate the two types of ability, it would likely > be implemented through the two flags currently defined in RA > (i.e., the M/O flags). > The main motivation of separating the two flags appear to be the > ability to suppress HCB (however strictly) by default, expecting > ICB is more common. > On the other hand, we now know combinations of these flags turn > out to be a confusing issue than we originally thought and can > cause weird corner for implementors. So, some people rather > wanted to unify those flags into a single bit, indicating whether > DHCPv6 service is available (whether it's HCB or ICB), and solve > HCB vs ICB issues through extensions to DHCPv6. > I've seen lots of opinions from many people for either side, and > their points are almost orthogonal. I'd not expect one side can > fully convince the other through further discussion. In my > understanding, however, people who preferred the single bit could > also live with the two bits. Also, possible extensions to DHCPv6 > may make the combinations issues easier to handle. So, possible > compromise here is to keep the two flags, and to clarify (or > perhaps mitigate) the combination issues with DHCPv6 extensions. > (I don't have a specific idea about how that can be done at this > moment though). > Requirement 3 is basically a trivial requirement unless we use very > strong prohibition (e.g., MUST NOT) for Requirement 1', and perhaps we > don't have to do anything about this. As some people pointed out, > users/implementations would always ignore specifications when they > want to do so. A minor issue is how we should be explicit about the > flexibility in a specification (or any document that comes from this > discussion). Perhaps we need to clarify the possibility explicitly in > order to avoid confusion, or perhaps we should not even mention that > since this is trivial and 'not IETF's business'. I guess this is > pretty minor, and we can postpone the decision until the other bigger > issues are resolved. > I hope this lengthy message can be a helpful and constructive source > of the next step for this discussion. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 11:24:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzycq-0002lR-PE; Tue, 02 Aug 2005 11:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzycp-0002lK-2A for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 11:24:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28463 for ; Tue, 2 Aug 2005 11:24:12 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzz9J-0005If-19 for ipv6@ietf.org; Tue, 02 Aug 2005 11:57:50 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j72FNwqA026736 for ; Tue, 2 Aug 2005 16:23:58 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA02057 for ; Tue, 2 Aug 2005 16:23:32 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j72FNWX22514 for ipv6@ietf.org; Tue, 2 Aug 2005 16:23:32 +0100 Date: Tue, 2 Aug 2005 16:23:31 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050802152331.GC21362@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <6.2.1.2.2.20050722134544.02cf9090@mailhost.iprg.nokia.com> <20050723.140110.115902850.fujisaki@syce.net> <23581AF9-3CBA-47B5-AE80-D9CEF16B87D7@arifumi.net> <0C82FA31-472D-4694-A2B2-926EB73D8BA8@arifumi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C82FA31-472D-4694-A2B2-926EB73D8BA8@arifumi.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Re: Proposed IPv6 W.G. Agenda for Paris X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Aug 02, 2005 at 07:22:09PM +0900, Arifumi Matsumoto wrote: > > Additionally, > at v6ops session yesterday, 6net people showed us another > possible usage of address selection policy table. It's renumbering. > By pouring address selection policy into each end hosts, > you can easily configure address selection policy that > makes end-hosts not to use old address. There were two 'interesting' states during the renumbering we did. 1) Both prefixes equally valid. Here the address selection was somewhat 'arbitary' on the four OSes we tested. In reality this didn't matter too much, but it might be nice to have a policy distribution method indicate a shift to prefer the new prefix before deprecating the old one. 2) Old prefix deprecated. In this case the four OSes all selected addresses correctly, i.e. preferred active over deprecated addresses. This allows the Baker process to basically work, at least for the host configuration aspect. As an aside, the undesirable property we observed after the deprecated address became invalid (removed) was that applications and tools continued to use that address as a source, but would never see replies. One assumes the address validity is only checked at bind time. But that raises the issue of how often the distributed policy is rechecked by the system or applications. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 11:27:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzyff-0004qW-UP; Tue, 02 Aug 2005 11:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzyfd-0004p5-JA; Tue, 02 Aug 2005 11:27:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28657; Tue, 2 Aug 2005 11:27:06 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzC7-0005SD-99; Tue, 02 Aug 2005 12:00:45 -0400 Received: from impact.jinmei.org (unknown [2001:688:ffff:4:e49b:cd88:b25e:3592]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AB7E11521A; Wed, 3 Aug 2005 00:27:04 +0900 (JST) Date: Wed, 03 Aug 2005 00:27:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ipv6@ietf.org Subject: Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org (This is mainly a matter of dhc wg, so I listed the ipv6 list in the cc field). Does anyone have an opinion on possible extensions to the DHCPv6 protocol (see below for more details)? Aside from the extension details, if we can accept introducing some extensions to meet the corresponding requirement, I think we can start working on the details in the dhc wg independently from the M/O flags discussion. At the very bottom line, my understanding is that we can accept some level of extensions to the current protocol...is that correct? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp >>>>> On Mon, 01 Aug 2005 06:39:12 +0900, >>>>> JINMEI Tatuya said: >> 2) Ability for a host to get all desired and available DHCP >> configuration with a single DHCP message exchange >> - if a host wants HCB, it sends an HCB request (Solicit) and receives >> HCB and/or ICB replies >> - if a host wants ICB, it sends an ICB request (Information-request) >> and receives ICB replies > (snip) >> Requirement 2 seems least controversial. In my understanding, this is >> basically for removing redundant probe packets or hopeless timeouts >> for unavailable service. In particular, we wanted to avoid scenario >> where an HCB client continues sending Solicits even if there is no HCB >> server but an ICB-only server, and even if the client can somehow >> benefit from the "ICB part" excluding addresses. Such a case is most >> likely a result from temporary dead servers or configuration errors, >> but we seem to have agreed that we want to deal with such cases. >> Requirement 2 can be met through some extensions to RFC3315 and >> RFC3736. > Assuming we basically agreed that the basic analysis I showed in my > previous message, I'd like to discuss more details about 'solutions'. > The followings are possible extensions to DHCPv6 I've seen so far: > A. make an ICB-only server reply to Solicit with an Advertise > including NoAddrsAvail and other configuration information (just > like a Reply to Information-request) > B. make an HCB client accept an Advertise even if it includes > NoAddrsAvail, if it gets no other Advertise including addresses, > the Advertise also includes other configuration information, and > the client can benefit from that information > C. allow an HCB client to fallback from HCB to ICB after some timeout > D. allow an HCB client to perform HCB and ICB concurrently > Extensions A and B help when the RA signal indicates the availability > of HCB (whether the signal is "1-bit" or "2-bit (for HCB and ICB)") > but no HCB server is actually available for some reason. One > debatable point is that Extension A requires a modification (an > additional feature) to ICB-only servers, which are expected to be > light-weight (note, however, that the ICB-only servers will still be > stateless even with the extension). > Extensions C and D concern an HCB client for which there is only an > ICB-only server that does not support extension A (i.e., it's a kind > of backward compatibility). We have multiple choices about these > extensions. > - If our consensus is we don't have to care about such compatibility, > we don't need either of those. > - If we really need something like those, then Extensions C and D are > almost exclusive with some tradeoffs: > + Extension C does not consume redundant bandwidth since ICB is not > invoked if a working HCB server exists. > + But it takes more time for the client to get other configuration > information via ICB if no HCB server but ICB server exists. > + Extension D ensures that the client can always get at least other > configuration information as quickly as possible. > + However, it consumes more bandwidth since the client will always > send ICB requests regardless of the existence of an HCB server. > The followings are my personal conclusions regarding the extensions. > I believe we can agree that extension B is acceptable. > Whether extension A is also acceptable or not probably depends on > whether we can accept "complicating" ICB-only servers. I guess we > need inputs from implementors, but, as one implementor of DHCPv6, I > think this is an acceptable modification. > Regarding extensions C and D, I can live with either: extension C > only, extension D only, or none of those, expecting we can introduce > extensions A and B (then newer implementations don't need either > extension C or D). But I'd slightly prefer introducing extension C. > This can be suboptimal (in terms of fallback delay) compared to > extension D, but I guess the advantage of less consumption of > bandwidth would be preferred because this is just a workaround with > older (without extension A) ICB-only servers. And I still believe > providing the workaround will help. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 11:48:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz0g-0004cP-7R; Tue, 02 Aug 2005 11:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz0c-0004cK-O1 for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 11:48:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00550 for ; Tue, 2 Aug 2005 11:48:47 -0400 (EDT) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzX7-0006ac-9k for ipv6@ietf.org; Tue, 02 Aug 2005 12:22:26 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRDHGTGVE299QR1M@vaxh.its.monash.edu.au> for ipv6@ietf.org; Wed, 03 Aug 2005 01:48:45 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A813F8000D for ; Wed, 03 Aug 2005 01:48:45 +1000 (EST) Received: from [172.19.242.30] (vpn-student-242-30.its.monash.edu.au [172.19.242.30]) by larry.its.monash.edu.au (Postfix) with ESMTP id D47CC3C005 for ; Wed, 03 Aug 2005 01:48:44 +1000 (EST) Date: Wed, 03 Aug 2005 01:48:42 +1000 From: Greg Daley To: ipv6@ietf.org Message-id: <42EF95DA.50503@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Subject: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, I think there are some interesting discussions going on in a different thread, but I thought I'd start a new thread in order to talk about a contentious issue without polluting the other. Regarding draft-pashby-ipv6-network-discovery-00.txt, this provides a mechanism for devices to be made respond to queries from another device on the IPv6 network. This is not an existing capability. I'm concerned that if there is a way to find out all the nodes on a link, that this information may be used (by the querier, or another device) to cause remote flooding attacks onto a network, or to particular otherwise unmodified hosts. In IPv4 it is feasible/trivial to try all addresses in a subnet in order to find targets for attack, but in IPv6 >2^60 combinations may need to be tried. The anonymity of the present (but quiet) IPv6 node is probably useful in this case. There is no system, except MLD which can force response from unknown nodes in IPv6. With MLD, the reporters can be made to expose only one of their link-local source addresses. They are not required to expose global addresses. At the moment there's no security for MLD, but the risk is limited to link-local addresses which are not vulnerable to off-link attacks. I'm loath to introduce a more generic function like this which exposes global IPv6 addresses, unless there is verifiable trust available to the nodes, before they are forced to respond. Greg. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 11:56:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz80-0003Mv-9q; Tue, 02 Aug 2005 11:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzz7y-0003M0-Tv for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 11:56:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01270 for ; Tue, 2 Aug 2005 11:56:24 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzeT-00070S-9S for ipv6@ietf.org; Tue, 02 Aug 2005 12:30:03 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRDHQ421CK8WZO0Y@vaxc.its.monash.edu.au> for ipv6@ietf.org; Wed, 03 Aug 2005 01:56:15 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C002AB543 for ; Wed, 03 Aug 2005 01:56:15 +1000 (EST) Received: from [172.19.242.30] (vpn-student-242-30.its.monash.edu.au [172.19.242.30]) by moe.its.monash.edu.au (Postfix) with ESMTP id 63E0C4FB04 for ; Wed, 03 Aug 2005 01:56:14 +1000 (EST) Date: Wed, 03 Aug 2005 01:56:11 +1000 From: Greg Daley To: ipv6@ietf.org Message-id: <42EF979B.9050505@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT Subject: How ready is IPv6 - do we need to describe it? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, I was chatting with Keith Moore, and think that it may help to provide guidance (a BCP) on which components are stable and reliable for IPv6 deployment. Perhaps it could be seen as a wrap-up for the IPv6 WG. It may be possible to indicate the standard levels at the time of writing, and indicate if there were known remanant issues (or uncertainty) with a particular protocol. This would give a clear idea of how far down the path to usability the suite of v6 tools is, so that operators can consider the state of the art before going ahead with deployment. Does anyone have an opinion on if it would be helpful or hurtful? Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 12:20:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzP1-0007no-Ed; Tue, 02 Aug 2005 12:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzOy-0007i5-P1 for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 12:14:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02533 for ; Tue, 2 Aug 2005 12:13:57 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzvT-0007pv-I4 for ipv6@ietf.org; Tue, 02 Aug 2005 12:47:37 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j72GDfD18365; Tue, 2 Aug 2005 18:13:41 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j72GDfNK012623; Tue, 2 Aug 2005 18:13:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508021613.j72GDfNK012623@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Gunter Van de Velde (gvandeve)" In-reply-to: Your message of Tue, 02 Aug 2005 17:04:34 +0200. <4.3.2.7.2.20050802165919.033d8480@strange-brew> Date: Tue, 02 Aug 2005 18:13:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org, Pekka Savola Subject: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: >=> I disagree: the problem still exists but in a different form: to make >a network map/topology you need to bind link-local and global addresses. Not sure. Why do you assume that the global address tells you anything about location? => it doesn't tell anything about location, it tells something about routers and their routes. Don't forget that IGPs fully work with link-local addresses only. It would be better to have something that maps identities of devices and at his turn potentially maps it into some kind of topologies. => you can't query a router if you have only its link-local address(es) and you are not on (one of) its link(s). It would be interesting however to have awareness of who is attached and with which addresses (a use example would be for ISP billing purposes). => and legal requirements for ISPs in Europe. There are techniques out there that allow this to be done, but i doubt if we need a protocol for this purpose as such. => network discovery is not for ISPs (if your ISP needs it, I suggest to change for another one)... It is for the poor new network manager who has only far from up to date maps of his network and needs to fix it Friday evening. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 12:20:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzPc-0000eY-2b; Tue, 02 Aug 2005 12:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzPa-0000e2-PN for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 12:14:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02555 for ; Tue, 2 Aug 2005 12:14:35 -0400 (EDT) Received: from smta08.mail.ozemail.net ([203.103.165.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzzw4-0007qm-JW for ipv6@ietf.org; Tue, 02 Aug 2005 12:48:14 -0400 Received: from ubu.nosense.org ([210.84.233.227]) by smta08.mail.ozemail.net with ESMTP id <20050802161428.ZKTQ4747.smta08.mail.ozemail.net@ubu.nosense.org>; Tue, 2 Aug 2005 16:14:28 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 35B5162B15; Wed, 3 Aug 2005 01:44:26 +0930 (CST) Date: Wed, 3 Aug 2005 01:44:25 +0930 From: Mark Smith To: Greg Daley Message-Id: <20050803014425.2b871da6.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <42EF95DA.50503@eng.monash.edu.au> References: <42EF95DA.50503@eng.monash.edu.au> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Greg, On Wed, 03 Aug 2005 01:48:42 +1000 Greg Daley wrote: > Hi, > > > At the moment there's no security for MLD, but the risk is > limited to link-local addresses which are not vulnerable to > off-link attacks. > Until malware, delivered as an email payload or via a socially engineered HTTP download, or some other "higher-than-layer-3/4" method takes advantage of that capability to discover nodes, and then do what ever it wants to them e.g. DoS them, or "call home" and then act as a relay betweem the offsite node and these link-local devices etc. I don't think the "on-link" limitation is all that much of one unfortunately. > I'm loath to introduce a more generic function like > this which exposes global IPv6 addresses, unless there is > verifiable trust available to the nodes, before they are > forced to respond. > I agree. It does unfortunately rely on only trusted programs using this trusted request feature - see above (sadly). Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 12:21:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzVs-00073n-9o; Tue, 02 Aug 2005 12:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzVq-0006yr-6F for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 12:21:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03001 for ; Tue, 2 Aug 2005 12:21:03 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E002J-00089Y-2r for ipv6@ietf.org; Tue, 02 Aug 2005 12:54:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Aug 2005 12:20:54 -0400 X-IronPort-AV: i="3.95,162,1120449600"; d="scan'208"; a="64887218:sNHT31277584" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j72GKsk6016388; Tue, 2 Aug 2005 12:20:54 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 12:20:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2005 12:20:53 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB217427B7@xmb-rtp-20a.amer.cisco.com> Thread-Topic: remarks (RE M/O Bits & Requirement 3) Thread-Index: AcWXcECctMq82C1UQoOySPOfpV+LxgAA79Gg From: "Bernie Volz \(volz\)" To: "Iljitsch van Beijnum" , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 02 Aug 2005 16:20:54.0119 (UTC) FILETIME=[27E91F70:01C5977E] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: remarks (RE M/O Bits & Requirement 3) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I believe requirement 3 is incorrectly stated; I think the discussion in the past was to have M=3D0/O=3D0 mean that the node SHOULD NOT start = DHCPv6. I believe it was just desired that it *NOT* be a MUST NOT. Just remember what RFC 2119 states regarding these two phrases: 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Several rasons to have SHOULD NOT at the present time are: 1. That several DHCPv6 clients today must be manually configured to run, likely because they don't have access to the M and O bits so can't make use of them. 2. There could be multiple RAs with conflicting M&O bits. 3. Or the M and O bits have changed and at least RFC 2462 states that only FALSE -> TRUE transitions trigger running the "stateful address configuration protocol" (and a TRUE -> FALSE transition does not cause the protocol to stop running). - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Iljitsch van Beijnum > Sent: Tuesday, August 02, 2005 10:38 AM > To: IETF IPv6 Mailing List > Subject: remarks >=20 > My remarks in the session just now: >=20 > IIRC, 24 bits of the address are encoded in the solicited node =20 > address, good luck finding hardware that can handle this many =20 > multicast groups. >=20 > I still would like to know what exactly requirement 3 would be: >=20 > - still DHCPv6 if routers send the default 00 MO bits, or > - "requirement" to do DHCPv6 always regardless what routers say >=20 > (Note that all I care about / anyone here should care about=20 > is out of =20 > the box behavior, if people configure their hosts to play the French =20 > national anthem when the O bit is set, which is clearly not mandated =20 > by any RFC, they can always do that. Vendors just shouldn't make it =20 > happen by default.) >=20 > The question: are there now implementations that do something =20 > different when the MO bits aren't 00 as opposed to when they are? =20 > I.e., what do we break by redifining these bits? >=20 > All the stuff I've seen in the wild just ignores the bits. >=20 > Iljitsch van Beijnum >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 12:48:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzwZ-0000TU-Lm; Tue, 02 Aug 2005 12:48:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzwX-0000ST-Lk for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 12:48:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04405 for ; Tue, 2 Aug 2005 12:48:38 -0400 (EDT) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00T2-0000vc-H4 for ipv6@ietf.org; Tue, 02 Aug 2005 13:22:17 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 66EDB552D; Tue, 2 Aug 2005 18:48:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 61A7F54FE; Tue, 2 Aug 2005 18:48:11 +0200 (CEST) Date: Tue, 2 Aug 2005 18:48:11 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Mark Smith In-Reply-To: <20050803014425.2b871da6.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: <20050802184442.D56297@mignon.ki.iif.hu> References: <42EF95DA.50503@eng.monash.edu.au> <20050803014425.2b871da6.ipng@69706e6720323030352d30312d31340a.nosense.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipv6@ietf.org, Greg Daley Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, 3 Aug 2005, Mark Smith wrote: > Hi Greg, > > On Wed, 03 Aug 2005 01:48:42 +1000 > Greg Daley wrote: > >> Hi, >> > > > >> >> At the moment there's no security for MLD, but the risk is >> limited to link-local addresses which are not vulnerable to >> off-link attacks. >> > > Until malware, delivered as an email payload or via a socially > engineered HTTP download, or some other "higher-than-layer-3/4" method > takes advantage of that capability to discover nodes, and then do what > ever it wants to them e.g. DoS them, or "call home" and then act as a > relay betweem the offsite node and these link-local devices etc. > > I don't think the "on-link" limitation is all that much of one > unfortunately. Agree, but we should not destroy this "on-link" limitation... > >> I'm loath to introduce a more generic function like >> this which exposes global IPv6 addresses, unless there is >> verifiable trust available to the nodes, before they are >> forced to respond. Agree. Regards, Janos Mohacsi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 12:48:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzwe-0000UB-62; Tue, 02 Aug 2005 12:48:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzwc-0000U6-Cy for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 12:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04408 for ; Tue, 2 Aug 2005 12:48:42 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00T5-0000wV-35 for ipv6@ietf.org; Tue, 02 Aug 2005 13:22:22 -0400 Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j72Gmdr3010004; Tue, 2 Aug 2005 10:48:39 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j72GmW2N818320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2005 09:48:34 -0700 (PDT) Message-ID: <42EFA40D.7070600@sun.com> Date: Tue, 02 Aug 2005 09:49:17 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Daley References: <42EF95DA.50503@eng.monash.edu.au> In-Reply-To: <42EF95DA.50503@eng.monash.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Greg Daley wrote: > I'm concerned that if there is a way to find out all the > nodes on a link, that this information may be used > (by the querier, or another device) to cause remote flooding > attacks onto a network, or to particular otherwise unmodified > hosts. That is the case if a remote node can do the discovery operation. But if the discovery operation is limited to nodes on the link, then we don't have the "remote" concern. I think that might be a reasonable middle ground. It would still make it harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP access to a local agent on the link that provide this (with appropriate SNMP security) to allow remote management. Elsewhere I've run into the management need to find a particular host from knowing only its MAC address. The suggestion to have INVARP would help with that subproblem. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 12:51:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzzC-0002C8-AJ; Tue, 02 Aug 2005 12:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzz8-0002Br-9i for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 12:51:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04678 for ; Tue, 2 Aug 2005 12:51:18 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00Vd-000165-El for ipv6@ietf.org; Tue, 02 Aug 2005 13:24:58 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j72GpDqA028750 for ; Tue, 2 Aug 2005 17:51:13 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA09406 for ; Tue, 2 Aug 2005 17:50:56 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j72GouM24819 for ipv6@ietf.org; Tue, 2 Aug 2005 17:50:56 +0100 Date: Tue, 2 Aug 2005 17:50:56 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050802165056.GB24298@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <42EF979B.9050505@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42EF979B.9050505@eng.monash.edu.au> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: Re: How ready is IPv6 - do we need to describe it? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Aug 03, 2005 at 01:56:11AM +1000, Greg Daley wrote: > Hi, > > I was chatting with Keith Moore, and think that it may > help to provide guidance (a BCP) on which components > are stable and reliable for IPv6 deployment. > > Perhaps it could be seen as a wrap-up for the IPv6 WG. I think any feedback/commentary is valuable, be it in ipv6 or v6ops WG. Some consensus on 'gaps' before Vancouver would be nice. > It may be possible to indicate the standard levels > at the time of writing, and indicate if there were > known remanant issues (or uncertainty) with a particular > protocol. Do you mean observations from operational experience, from interop tests in 'clinical' environments or 'uncertainty' from a theoretical perspective? > This would give a clear idea of how far down the path > to usability the suite of v6 tools is, so that operators > can consider the state of the art before going ahead > with deployment. It depends what path you're on. Personally, we see IPv6 as deployable now in a dual-stack academic backbone/enterprise environment, indeed we have IPv6 deployed without adverse impact on IPv4. We've been through the renumbering process - albeit on a 'small' enterprise that you say doesn't exist. I think the renumbering gaps are more tool issues than protocol issues, though we may need protocols defined to allow any emergent vendor tools to interoperate. So I think different people will see different 'gaps', some may/will see none or at least none that are show-stoppers. > Does anyone have an opinion on if it would be helpful > or hurtful? I think it would be helpful. One result might be an ipv6 WG recharter? Closure may be a little premature. I'm not sure I like the idea of a 'political message' that IPv6 is 'ready', I would rather see the WG tackle genuine issues, and I don't think standards should be advanced to fuller status until they have been static (and in use) for a reasonable period of time. It seems odd to advance something that's just popping off the -bis conveyor belt now, and how many issues did the issue trackers track for those, albeit the majority being quite minor? That said, many people are deploying and running IPv6 today. -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 12:57:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E004c-0004xD-7a; Tue, 02 Aug 2005 12:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E004Z-0004vE-O8 for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 12:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05207 for ; Tue, 2 Aug 2005 12:56:56 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00b4-0001NE-LT for ipv6@ietf.org; Tue, 02 Aug 2005 13:30:36 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j72GuXD20998; Tue, 2 Aug 2005 18:56:33 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j72GuYUp012809; Tue, 2 Aug 2005 18:56:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508021656.j72GuYUp012809@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Greg Daley In-reply-to: Your message of Wed, 03 Aug 2005 01:48:42 +1000. <42EF95DA.50503@eng.monash.edu.au> Date: Tue, 02 Aug 2005 18:56:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org I don't like multicast-based random discovery but about the security it is why we have scoped multicast... Regards Francis.Dupont@enst-bretagne.fr PS: I am in favor of as possible passive mechanisms, and in my IMHO too active mechanisms won't get better result just because too many devices will be configured to not answer. Here examples are ND table dumps via SNMP and multicated echo requests. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 13:14:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00LL-0006O4-94; Tue, 02 Aug 2005 13:14:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00LI-0006Nw-Lq for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 13:14:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06365 for ; Tue, 2 Aug 2005 13:14:12 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00ri-0002Ci-QW for ipv6@ietf.org; Tue, 02 Aug 2005 13:47:52 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j72HE8qA029098 for ; Tue, 2 Aug 2005 18:14:08 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA11216 for ; Tue, 2 Aug 2005 18:13:49 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j72HDnA25517 for ipv6@ietf.org; Tue, 2 Aug 2005 18:13:49 +0100 Date: Tue, 2 Aug 2005 18:13:49 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050802171349.GE24298@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <42EF95DA.50503@eng.monash.edu.au> <42EFA40D.7070600@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42EFA40D.7070600@sun.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Aug 02, 2005 at 09:49:17AM -0700, Erik Nordmark wrote: > > That is the case if a remote node can do the discovery operation. But if > the discovery operation is limited to nodes on the link, then we don't > have the "remote" concern. > > I think that might be a reasonable middle ground. It would still make it > harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP > access to a local agent on the link that provide this (with appropriate > SNMP security) to allow remote management. It's important that the solution allows the tool to discover multiple addresses used by a single node, i.e. the management view should show a multiaddressed node (e.g. two globals and seven RFC3041 addresses on one node) and not believe it's viewing multiple separate nodes (which is a fault that a number of existing tools have, as we witnessed when running some renumbering scenario tests). It's important that multiaddressing is considered normal behaviour for management of IPv6 nodes. -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 13:50:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00uG-0005AA-Kc; Tue, 02 Aug 2005 13:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00uE-00059m-CS for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 13:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08123 for ; Tue, 2 Aug 2005 13:50:20 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E01Qj-0003ft-O4 for ipv6@ietf.org; Tue, 02 Aug 2005 14:23:59 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j72HoJqA000093 for ; Tue, 2 Aug 2005 18:50:19 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA13267 for ; Tue, 2 Aug 2005 18:49:51 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j72HnoB26446 for ipv6@ietf.org; Tue, 2 Aug 2005 18:49:50 +0100 Date: Tue, 2 Aug 2005 18:49:50 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050802174950.GK24298@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: Policy for use of privacy addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, I raised this question today but we were short of time. My concern is that in an enterprise deployment, I might want to avoid the complexity of privacy addresses (from the management perspective). The context today was that in the proposal to distribute address selection policy (RFC3484) by DHCP (which I think is a nice idea, as we need some way to do that), how would one express preference for privacy over public for source address (or vice versa), given privacy addresses aren't prefix specific? I think 3484 says use globals in preference to private addresses by default. In a managed DHC environment, privacy addresses can be returned by DHCPv6 for client use, but my reading of RFC3315 suggests (section 12) that the request is client initiated, which implies there should/could be some policy that could be distributed by DHCP itself to hint to the client that it can make the request. I appreciate Keith's point that per-application (non) usage may also be desirable, but there is an API being proposed for that? It should probably have some relationship to the site policy though? I can also see in some environments that privacy usage may be quite normal, e.g. in unmanged home networks or wifi hotspots, but I'm just curious as to how their usage could be controlled in a managed enterprise. Or would one assume the DHC server allocting the privacy addresses is responsible for tracking which hosts (via DUIDs?) are allocated which addresses over time, and communicating that information to the management platforms? -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 02 16:14:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E037Y-00051n-LC; Tue, 02 Aug 2005 16:12:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E037W-00051i-5u for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 16:12:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15237 for ; Tue, 2 Aug 2005 16:12:11 -0400 (EDT) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E03e4-0000jp-0X for ipv6@ietf.org; Tue, 02 Aug 2005 16:45:52 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Tue, 2 Aug 2005 20:12:12 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw11c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Tue, 2 Aug 2005 20:11:58 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Aug 2005 15:10:53 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9767CF@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: Re: about draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcWXnaEdxgme2ItPRpKMXOCrP+iPVwAAJzvw From: "Pashby, Ronald W CTR NSWCDD-B35" To: X-OriginalArrivalTime: 02 Aug 2005 20:10:53.0257 (UTC) FILETIME=[48D67B90:01C5979E] X-Spam-Score: 0.5 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331694592==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0331694592== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5979E.491ED9A8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5979E.491ED9A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Greg, et. al, >=20 > You stated: > >Regarding draft-pashby-ipv6-network-discovery-00.txt, > >this provides a mechanism for devices to be made respond > >to queries from another device on the IPv6 network. > >This is not an existing capability. > > > >I'm concerned that if there is a way to find out all the > >nodes on a link, that this information may be used > >(by the querier, or another device) to cause remote flooding > >attacks onto a network, or to particular otherwise unmodified > >hosts. >=20 > The mechanism already exists. It is ICMP Echo to an "all hosts = multicast" address. My proposal=20 > limits the effect by placing a hold-off timer to stop flooding of the = network (and the quering device) >=20 > >The anonymity of the present (but quiet) IPv6 node is > >probably useful in this case. > > > >There is no system, except MLD which can force response from > >unknown nodes in IPv6. With MLD, the reporters can be made to > >expose only one of their link-local source addresses. > >They are not required to expose global addresses. >=20 > I agree that in some circumstances that would be ok. But in other = cases, it is extremely important to=20 > know what devices are connected to the network and what addresses = those devices are using. I have=20 > been around "well managed" networks as well as "secure" networks and = in both environments this is=20 > needed. >=20 > Passive listening to MLD does not yield enough infomation since the = group you join is only the low 24=20 > bits of the address and you have no idea of the high 108 bits. And = depending on your layer 2 technology=20 > you might not see the join if the monitor was not turned on when the = device is booted. This would require=20 > that you reboot all devices (including all the network gear, and the = order would be important) after you=20 > start you monitoring device.=20 >=20 > >At the moment there's no security for MLD, but the risk is > >limited to link-local addresses which are not vulnerable to > >off-link attacks. > > > >I'm loath to introduce a more generic function like > >this which exposes global IPv6 addresses, unless there is > >verifiable trust available to the nodes, before they are > >forced to respond. >=20 > I would be in favor of limiting the responses for Inverse Neighbor = Discovery and Node Information Queries to onlink requests (i.e. Hop = count must =3D 255). >=20 > Ron >=20 ------_=_NextPart_001_01C5979E.491ED9A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Re: about draft-pashby-ipv6-network-discovery-00.txt

Greg, et. al,

You stated:
>Regarding = draft-pashby-ipv6-network-discovery-00.txt,
>this provides a mechanism = for devices to be made respond
>to queries from another = device on the IPv6 network.
>This is not an existing = capability.
>
>I'm concerned that if there = is a way to find out all the
>nodes on a link, that this = information may be used
>(by the querier, or another = device) to cause remote flooding
>attacks onto a network, or = to particular otherwise unmodified
>hosts.

The mechanism already exists. It is = ICMP Echo to an "all hosts multicast" address. My proposal =
limits the effect by placing a = hold-off timer to stop flooding of the network (and the quering = device)

>The anonymity of the present = (but quiet) IPv6 node is
>probably useful in this = case.
>
>There is no system, except = MLD which can force response from
>unknown nodes in IPv6. With = MLD, the reporters can be made to
>expose only one of their = link-local source addresses.
>They are not required to = expose global addresses.

I agree that in some circumstances that = would be ok. But in other cases, it is extremely important to
know what devices are connected to the = network and what addresses those devices are using. I have
been around "well managed" = networks as well as "secure" networks and in both environments = this is
needed.

Passive listening to MLD does not yield = enough infomation since the group you join is only the low 24
bits of the address and you have no = idea of the high 108 bits. And depending on your layer 2 technology =
you might not see the join if the = monitor was not turned on when the device is booted. This would require =
that you reboot all devices (including = all the network gear, and the order would be important) after you =
start you monitoring device.

>At the moment there's no = security for MLD, but the risk is
>limited to link-local = addresses which are not vulnerable to
>off-link attacks.
>
>I'm loath to introduce a = more generic function like
>this which exposes global = IPv6 addresses, unless there is
>verifiable trust available = to the nodes, before they are
>forced to respond.

I would be in favor of limiting = the responses for Inverse Neighbor Discovery and Node Information = Queries to onlink requests (i.e. Hop count must =3D 255).

Ron

------_=_NextPart_001_01C5979E.491ED9A8-- --===============0331694592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0331694592==-- From ipv6-bounces@ietf.org Tue Aug 02 22:41:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E09CF-0006pA-CJ; Tue, 02 Aug 2005 22:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E09CD-0006p0-Kw for ipv6@megatron.ietf.org; Tue, 02 Aug 2005 22:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02194 for ; Tue, 2 Aug 2005 22:41:26 -0400 (EDT) Received: from smta02.mail.ozemail.net ([203.103.165.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E09ih-0006Cn-4V for ipv6@ietf.org; Tue, 02 Aug 2005 23:15:11 -0400 Received: from ubu.nosense.org ([210.84.233.227]) by smta02.mail.ozemail.net with ESMTP id <20050803024110.ETMV650.smta02.mail.ozemail.net@ubu.nosense.org>; Wed, 3 Aug 2005 02:41:10 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id F05A662B15; Wed, 3 Aug 2005 12:11:04 +0930 (CST) Date: Wed, 3 Aug 2005 12:11:04 +0930 From: Mark Smith To: Mohacsi Janos Message-Id: <20050803121104.2833134f.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050802184442.D56297@mignon.ki.iif.hu> References: <42EF95DA.50503@eng.monash.edu.au> <20050803014425.2b871da6.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050802184442.D56297@mignon.ki.iif.hu> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Mohacsi, Greg, On Tue, 2 Aug 2005 18:48:11 +0200 (CEST) Mohacsi Janos wrote: > > > > > On Wed, 3 Aug 2005, Mark Smith wrote: > > > Hi Greg, > > > > On Wed, 03 Aug 2005 01:48:42 +1000 > > Greg Daley wrote: > > > >> Hi, > >> > > > > > > > >> > >> At the moment there's no security for MLD, but the risk is > >> limited to link-local addresses which are not vulnerable to > >> off-link attacks. > >> > > > > Until malware, delivered as an email payload or via a socially > > engineered HTTP download, or some other "higher-than-layer-3/4" method > > takes advantage of that capability to discover nodes, and then do what > > ever it wants to them e.g. DoS them, or "call home" and then act as a > > relay betweem the offsite node and these link-local devices etc. > > > > I don't think the "on-link" limitation is all that much of one > > unfortunately. > > Agree, but we should not destroy this "on-link" limitation... > I also agree with that. One thing I've realised overnight is that most "entities" (animals, miltary, etc.) that use hiding as a security method don't have it as their only security method. They usually use it as a first line of defence, albeit not a very strong one. It might work, and if it does, that's all well and good. If it doesn't, they have at least one or more much more secondary security methods e.g. being able to run away very quickly. Learning from that example, it probably means that while the hiding property of IPv6 addressing is useful, it isn't all that strong a security mechanism, and in particular, shouldn't be the only one relied on. Therefore, while I certainly think we should try to preserve it in Ipv6, we shouldn't necessarily blindly think that if it is somewhat easily overcome (e.g., my example from above), we have a serious problem. Other techniques, such as host based firewalling for example, need to be in place if the hiding measures are overcome. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 02:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0D8Z-0008KP-Lc; Wed, 03 Aug 2005 02:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0D8X-0008Ig-2m for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 02:53:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18874 for ; Wed, 3 Aug 2005 02:53:55 -0400 (EDT) Received: from srv0010.pine.nl ([213.156.9.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Df8-0007DA-Ja for ipv6@ietf.org; Wed, 03 Aug 2005 03:27:40 -0400 Received: from localhost (localhost [127.0.0.1]) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id 74CE7435B47; Wed, 3 Aug 2005 08:53:45 +0200 (CEST) Received: from srv0010.pine.nl ([127.0.0.1]) by localhost (srv0010.pine.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 59940-02-30; Wed, 3 Aug 2005 08:53:22 +0200 (CEST) Received: from [86.255.25.45] (open-25-45.ietf63.ietf.org [86.255.25.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id A24D4435B25; Wed, 3 Aug 2005 08:53:22 +0200 (CEST) In-Reply-To: <200508021341.JAA19303@ietf.org> References: <200508021341.JAA19303@ietf.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 2 Aug 2005 23:20:11 +0200 To: Tony Hain X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-new at pine.nl X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: M & O bit discussion today X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2-aug-2005, at 15:41, Tony Hain wrote: > I choose not to try to get to the mic, but on the debated > requirement point > 3; why is there a belief that the DHCP relay information is correctly > configured if the simpler set of 2 bits is improperly configured? I think a case can be made for the notion that most routers and most networks don't implement the bits today, so seeing MO==00 doesn't really authoratively say there is no DHCP service, but just that the routers operate in a default configuration. So it would be useful to redefine MO==00 to mean "no opinion" and come up with a new value that indicates authoritative information that DHCPv6 is unavailable and/or shouldn't be used. > I agree that point 1 & 3 are in direct conflict and that 1 is the real > requirement. In the scenario above that wouldn't be the case. (Having DHCPv6=Y/unknown/DHCPv6=N also increases the likelihood that OS vendors will be prepared to enable DHCPv6 when MO==00 by default, they may / hopefully will not want to do this if there is no other way to indicate the absence of DHCPv6 servers.) > Hosts should never try to outguess the specific instructions from the > router... Agree, especially in this case where it leads to continuous extra multicast traffic (don't forget that multicast takes up much more bandwidth than unicast on wifi, a reason why we should think twice about draft-pashby-ipv6-network-discovery-00.txt). > This means that even the case of M & O clear without a prefix > should not result in a DHCP request. This only invites rouge DHCP > servers as > a DOS attack. One valid case for M & O clear without a prefix would > be a > router retracting the delegated prefix when the link associated > with that > prefix fails. When all such upstream links fail there should be no > prefix > unless the network manager has configured a ULA prefix. The lack of > a prefix > is not a configuration error, I believe it is: the router is still advertising itself as a router, implying it can reach the rest of the world. This is harmful. (I think there is a need to study the permutations of different prefix and RA timeouts and their effects, I'll bring that up in v6ops.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 03:01:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DFz-000296-7p; Wed, 03 Aug 2005 03:01:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DFx-00028A-FN for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 03:01:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19440 for ; Wed, 3 Aug 2005 03:01:36 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0DmZ-0007ZP-WA for ipv6@ietf.org; Wed, 03 Aug 2005 03:35:21 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7371OTb019956 for ; Wed, 3 Aug 2005 09:01:24 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7371Nfv009838 for ; Wed, 3 Aug 2005 09:01:23 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7371Nld009837 for ipv6@ietf.org; Wed, 3 Aug 2005 09:01:23 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 3 Aug 2005 09:01:23 +0200 From: Stig Venaas To: ipv6@ietf.org Message-ID: <20050803070123.GA9117@storhaugen.uninett.no> References: <20050802174950.GK24298@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802174950.GK24298@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: Re: Policy for use of privacy addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Aug 02, 2005 at 06:49:50PM +0100, Tim Chown wrote: > Hi, > > I raised this question today but we were short of time. > > My concern is that in an enterprise deployment, I might want to avoid the > complexity of privacy addresses (from the management perspective). Right, I'm not sure if that necessary relates to source address selection though. In such cases I think it better that the interfaces get no privacy addresses at all. [...] > I appreciate Keith's point that per-application (non) usage may also be > desirable, but there is an API being proposed for that? It should probably > have some relationship to the site policy though? In particular for privacy addresses I see a need for per-application behaviour. One concern I have is how applications can distinguish privacy addresses from others. There are apps that need to e.g. find all addresses on an interface or host, and then register some of those somewhere (or pass them as a referral or otherwise to a peer/server). It probably would like to use a stable address and not privacy address for this, but how does it find which are which? Apps shouldn't need to try to guess from the interface id... In the above setting I also see issues with "normal" global vs ULA. An application may need to distinguish them and somehow know which to use. Distinguishing them is easy, knowing which of them to pass may not be trivial. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 03:22:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DZm-0001RG-Pn; Wed, 03 Aug 2005 03:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DZj-0001OQ-Vp for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 03:22:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20539 for ; Wed, 3 Aug 2005 03:22:02 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0E6N-0008RT-MG for ipv6@ietf.org; Wed, 03 Aug 2005 03:55:48 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j737LgD05020; Wed, 3 Aug 2005 09:21:42 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j737Lg3a014774; Wed, 3 Aug 2005 09:21:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508030721.j737Lg3a014774@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Chown In-reply-to: Your message of Tue, 02 Aug 2005 18:13:49 BST. <20050802171349.GE24298@login.ecs.soton.ac.uk> Date: Wed, 03 Aug 2005 09:21:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ipv6@ietf.org Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: It's important that the solution allows the tool to discover multiple addresses used by a single node, i.e. the management view should show a multiaddressed node (e.g. two globals and seven RFC3041 addresses on one node) and not believe it's viewing multiple separate nodes (which is a fault that a number of existing tools have, as we witnessed when running some renumbering scenario tests). => my default passive tool (ND table dump on routers via MIB/SNMP) gives all in use addresses of hosts and all addresses of routers. Explicit queries of hosts by SNMP or ICMP name lookups should give more (even too much :-). It's important that multiaddressing is considered normal behaviour for management of IPv6 nodes. => I fully agree. Francis.Dupont@enst-bretagne.fr PS: for hosts the question is about direct or indirect management: direct gives more but needs tools (agents) on each host and raises security/privacy issues. Indirect is more standard but works only for "active" hosts, usually it is enough because "inactive"/invisible nodes are less sources of troubles. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 03:28:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DgJ-0005Qv-R0; Wed, 03 Aug 2005 03:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DgG-0005La-Sm; Wed, 03 Aug 2005 03:28:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20836; Wed, 3 Aug 2005 03:28:47 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ECt-0000Iv-Ow; Wed, 03 Aug 2005 04:02:33 -0400 Received: from [86.255.30.209] (open-30-209.ietf63.ietf.org [86.255.30.209]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 2BB3F568AA; Wed, 3 Aug 2005 00:28:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Ted Lemon Date: Wed, 3 Aug 2005 09:28:14 +0200 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Aug 2, 2005, at 5:27 PM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: > At the > very bottom line, my understanding is that we can accept some level of > extensions to the current protocol...is that correct? Yes, I think that's correct. The one extension I heard proposed, =20 which made stateless DHCP more compatible with stateful, seemed =20 pretty low-impact. So I think it's okay. As for the MUST vs. SHOULD issue (item 3), I think it should be a =20 SHOULD, not a MUST. I think that there are environments (e.g., =20 possibly cell phone) where it should be a MUST, but that is something =20= that should be dealt with in the standards bodies that talk about =20 cell phones, not in the IETF. There was also some question in the past of what to do when the M and =20= O bits *change* between router advertisements. I can't remember who =20= brought it up. I don't recall seeing any resolution to this. =20 While secure RA sounds really neat, I suspect it will not be widely =20 usable on networks where ad-hoc connection is the norm (e.g., SOHO =20 and WiFi hotspots). If my gut feeling on this is correct, then how =20 we deal with the case where we get an RA with bad information really =20 is important. If a bad RA kills my IP connectivity, that's a big =20 problem. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 03:32:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Dk7-0006z6-FM; Wed, 03 Aug 2005 03:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Dk5-0006yz-75 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 03:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21023 for ; Wed, 3 Aug 2005 03:32:43 -0400 (EDT) Received: from smta02.mail.ozemail.net ([203.103.165.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EGi-0000Zc-Gd for ipv6@ietf.org; Wed, 03 Aug 2005 04:06:29 -0400 Received: from ubu.nosense.org ([210.84.233.227]) by smta02.mail.ozemail.net with ESMTP id <20050803073236.HJXU650.smta02.mail.ozemail.net@ubu.nosense.org>; Wed, 3 Aug 2005 07:32:36 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id CDDE562B15; Wed, 3 Aug 2005 17:02:34 +0930 (CST) Date: Wed, 3 Aug 2005 17:02:34 +0930 From: Mark Smith To: "Pashby, Ronald W CTR NSWCDD-B35" Message-Id: <20050803170234.18a90848.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <041052AD735329479241C23E0813EB7E9767CF@NAEAMILLEX05VA.nadsusea.nads.navy.mil> References: <041052AD735329479241C23E0813EB7E9767CF@NAEAMILLEX05VA.nadsusea.nads.navy.mil> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Ron, On Tue, 2 Aug 2005 15:10:53 -0500 "Pashby, Ronald W CTR NSWCDD-B35" wrote: > > Greg, et. al, > > > > You stated: > > >Regarding draft-pashby-ipv6-network-discovery-00.txt, > > >this provides a mechanism for devices to be made respond > > >to queries from another device on the IPv6 network. > > >This is not an existing capability. > > > > > >I'm concerned that if there is a way to find out all the > > >nodes on a link, that this information may be used > > >(by the querier, or another device) to cause remote flooding > > >attacks onto a network, or to particular otherwise unmodified > > >hosts. > > > > The mechanism already exists. It is ICMP Echo to an "all hosts multicast" address. My proposal > > limits the effect by placing a hold-off timer to stop flooding of the network (and the quering device) > > > > >The anonymity of the present (but quiet) IPv6 node is > > >probably useful in this case. > > > > > >There is no system, except MLD which can force response from > > >unknown nodes in IPv6. With MLD, the reporters can be made to > > >expose only one of their link-local source addresses. > > >They are not required to expose global addresses. > > Only if they respond to the multicast echo request. > > I agree that in some circumstances that would be ok. But in other cases, it is extremely important to > > know what devices are connected to the network and what addresses those devices are using. I have > > been around "well managed" networks as well as "secure" networks and in both environments this is > > needed. > > Looking at your .mil email address, am I right in assuming that you're after this capability to be able to attempt to find unauthorised hosts, rather than using it to get an indication of the number of hosts attached to the network ? If you're interested in this for security purposes, I'd think it wouldn't be all that effective. A knowledgable adversary will just configure their host not to respond to multicast echo requests. > > Passive listening to MLD does not yield enough infomation since the group you join is only the low 24 > > bits of the address and you have no idea of the high 108 bits. And depending on your layer 2 technology > > you might not see the join if the monitor was not turned on when the device is booted. This would require > > that you reboot all devices (including all the network gear, and the order would be important) after you > > start you monitoring device. > > > > >At the moment there's no security for MLD, but the risk is > > >limited to link-local addresses which are not vulnerable to > > >off-link attacks. > > > (Just for completeness, I've mentioned this in another, related thread) They can be vulnerable, if one of the locally attached nodes has running malware that will act as a relay / proxy for an offlink attacker. This malware could be delivered via a email payload for example, and then establish an outgoing connection to the offlink attacker. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 03:34:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Dlv-0007qr-18; Wed, 03 Aug 2005 03:34:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Dls-0007oD-LB for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 03:34:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21198 for ; Wed, 3 Aug 2005 03:34:35 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EIV-0000g4-H8 for ipv6@ietf.org; Wed, 03 Aug 2005 04:08:20 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j737XlD05946; Wed, 3 Aug 2005 09:33:47 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j737XlET014823; Wed, 3 Aug 2005 09:33:47 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508030733.j737XlET014823@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Chown In-reply-to: Your message of Tue, 02 Aug 2005 18:49:50 BST. <20050802174950.GK24298@login.ecs.soton.ac.uk> Date: Wed, 03 Aug 2005 09:33:47 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipv6@ietf.org Subject: Re: Policy for use of privacy addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: In a managed DHC environment, privacy addresses can be returned by DHCPv6 for client use, but my reading of RFC3315 suggests (section 12) that the request is client initiated, which implies there should/could be some policy that could be distributed by DHCP itself to hint to the client that it can make the request. I appreciate Keith's point that per-application (non) usage may also be desirable, but there is an API being proposed for that? It should probably have some relationship to the site policy though? => this point is supposed to be solved by RFC 3484 and related APIs but: - the private/public address switch (rule 7) is not in the policy table - related APIs assume that every applications were changed in order to use them (so they are nearly useless). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 03:37:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DoD-0000MZ-Dz; Wed, 03 Aug 2005 03:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DoA-0000L5-E2 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 03:36:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21375 for ; Wed, 3 Aug 2005 03:36:56 -0400 (EDT) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0EKn-0000oE-7f for ipv6@ietf.org; Wed, 03 Aug 2005 04:10:42 -0400 Received: (qmail 2298 invoked by uid 417); 3 Aug 2005 07:36:45 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 3 Aug 2005 07:36:45 -0000 Received: from mehr ([132.70.220.115]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 03 Aug 2005 01:36:44 -0600 Message-ID: <00b001c597fe$13236020$0401a8c0@mtc.ki.se> From: "Eric Klein" To: ipv6@ietf.org References: <42EF95DA.50503@eng.monash.edu.au> <42EFA40D.7070600@sun.com> Date: Wed, 3 Aug 2005 10:36:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Erik Nordmark wrote: > I think that might be a reasonable middle ground. It would still make it > harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP > access to a local agent on the link that provide this (with appropriate > SNMP security) to allow remote management. > > Elsewhere I've run into the management need to find a particular host > from knowing only its MAC address. The suggestion to have INVARP would > help with that subproblem. I agree that the security issues here are great, and that there is a need in the Management world for this feature. If you could limit this to an SNMP v3 secure function and not a IPv6 function then maybe we could work this out within the security concerns of all involved. But that is a different WG (I think that the SNMP v3 WG was closed down last year) so I would be real careful in how we proceed. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 03:40:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Drv-0006m8-1w; Wed, 03 Aug 2005 03:40:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Drs-0006gu-EA for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 03:40:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21790 for ; Wed, 3 Aug 2005 03:40:47 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EOV-00012M-Ix for ipv6@ietf.org; Wed, 03 Aug 2005 04:14:32 -0400 Received: by wproxy.gmail.com with SMTP id 68so97235wri for ; Wed, 03 Aug 2005 00:40:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=dOiKsWmZSoYk0FwKk8uPUyNazjHMNH+i+lYO8LXtw51muJWhtKlCWd2Ll687jPjzZ7aCzLO6Z6X+0ngsYMJXpmmxJRJoxfRilbz+zTAGXd3smWrjrR734d+apDa8nKA/CCHB3MV4zek/LekkKnvAlM+BNztuTuncE/SXKcplQ2c= Received: by 10.54.7.21 with SMTP id 21mr356950wrg; Wed, 03 Aug 2005 00:40:38 -0700 (PDT) Received: by 10.54.96.9 with HTTP; Wed, 3 Aug 2005 00:40:38 -0700 (PDT) Message-ID: Date: Wed, 3 Aug 2005 13:10:38 +0530 From: Srinivas Goud To: ipv6@ietf.org Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: IPv6 Final Destination Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1992832321==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1992832321== Content-Type: multipart/alternative; boundary="----=_Part_736_4022607.1123054838263" ------=_Part_736_4022607.1123054838263 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello All,=20 Is Final Destination Option (just before upper layer protocol), mutable or= =20 immutable? Can I assume that Destination Options inside AH (before AH) are mutable and= =20 Destination Option outside AH (after AH) as Immutable? Thanks in advance, Srinivas. ------=_Part_736_4022607.1123054838263 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello All,
Is Final Destination Option (just before upper layer protocol), mutable or = immutable?
Can I assume that Destination Options inside AH (before AH) are mutable and Destination Option outside AH (after AH) as Immutable?

Thanks in advance,
Srinivas.

------=_Part_736_4022607.1123054838263-- --===============1992832321== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1992832321==-- From ipv6-bounces@ietf.org Wed Aug 03 03:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0E1E-0004T3-Lq; Wed, 03 Aug 2005 03:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0E1C-0004Sv-M8 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 03:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22336 for ; Wed, 3 Aug 2005 03:50:25 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EXn-0001SU-DG for ipv6@ietf.org; Wed, 03 Aug 2005 04:24:10 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j737oLTb031693; Wed, 3 Aug 2005 09:50:21 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j737oLCO010285; Wed, 3 Aug 2005 09:50:21 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j737oKVd010284; Wed, 3 Aug 2005 09:50:20 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 3 Aug 2005 09:50:20 +0200 From: Stig Venaas To: Iljitsch van Beijnum Message-ID: <20050803075020.GA10247@storhaugen.uninett.no> References: <200508021341.JAA19303@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ipv6@ietf.org, Tony Hain Subject: Re: M & O bit discussion today X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Aug 02, 2005 at 11:20:11PM +0200, Iljitsch van Beijnum wrote: > On 2-aug-2005, at 15:41, Tony Hain wrote: > > >I choose not to try to get to the mic, but on the debated > >requirement point > >3; why is there a belief that the DHCP relay information is correctly > >configured if the simpler set of 2 bits is improperly configured? > > I think a case can be made for the notion that most routers and most > networks don't implement the bits today, so seeing MO==00 doesn't > really authoratively say there is no DHCP service, but just that the > routers operate in a default configuration. This sounds like a good suggestion to me. > So it would be useful to redefine MO==00 to mean "no opinion" and > come up with a new value that indicates authoritative information > that DHCPv6 is unavailable and/or shouldn't be used. I believe they should indicate whether DHCPv6 is available or not (possibly also stateful/stateless). Clients should then generally not do DHCP when they are told it isn't available (in particular with the "no opinion" option, there shouldn't be a need to try). If clients are told DHCP is available they could still choose not to use DHCP based on the client configuration, type of client etc. I don't want the bits to tell clients to do or not do DHCP request, because on a link there may be some clients that should not do DHCP at all, while others that need DHCP to function. > >I agree that point 1 & 3 are in direct conflict and that 1 is the real > >requirement. > > In the scenario above that wouldn't be the case. > > (Having DHCPv6=Y/unknown/DHCPv6=N also increases the likelihood that > OS vendors will be prepared to enable DHCPv6 when MO==00 by default, > they may / hopefully will not want to do this if there is no other > way to indicate the absence of DHCPv6 servers.) Without the "no info", vendors may have to set the default to say DHCP is available. I would rather see "no info". Stig > >Hosts should never try to outguess the specific instructions from the > >router... > > Agree, especially in this case where it leads to continuous extra > multicast traffic (don't forget that multicast takes up much more > bandwidth than unicast on wifi, a reason why we should think twice > about draft-pashby-ipv6-network-discovery-00.txt). > > >This means that even the case of M & O clear without a prefix > >should not result in a DHCP request. This only invites rouge DHCP > >servers as > >a DOS attack. One valid case for M & O clear without a prefix would > >be a > >router retracting the delegated prefix when the link associated > >with that > >prefix fails. When all such upstream links fail there should be no > >prefix > >unless the network manager has configured a ULA prefix. The lack of > >a prefix > >is not a configuration error, > > I believe it is: the router is still advertising itself as a router, > implying it can reach the rest of the world. This is harmful. (I > think there is a need to study the permutations of different prefix > and RA timeouts and their effects, I'll bring that up in v6ops.) > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 04:07:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EHo-0007yE-BI; Wed, 03 Aug 2005 04:07:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0EHl-0007xm-Mn for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 04:07:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23321 for ; Wed, 3 Aug 2005 04:07:32 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0EoP-0002FE-T7 for ipv6@ietf.org; Wed, 03 Aug 2005 04:41:18 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 01:07:17 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 01:07:16 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 01:07:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 01:07:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2005 01:07:09 -0700 Message-ID: Thread-Topic: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcWX/e74Qgc3YlU8QjiyYihZOxfriQAA90Nw From: "Christian Huitema" To: "Mark Smith" , "Pashby, Ronald W CTR NSWCDD-B35" X-OriginalArrivalTime: 03 Aug 2005 08:07:15.0581 (UTC) FILETIME=[5C4CA2D0:01C59802] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > Only if they respond to the multicast echo request. Reality check: by default, host firewalls drop incoming echo requests. An explicit design goal of these firewalls is to make the host "stealthy", i.e. make sure the host is only detected by parties with which the host decide to communicate. I don't believe that polling protocols can reliably provide inventory. If you really want inventory, you probably will have better luck with a layer 2 access control protocol (802.1x), or by using a router based tool to monitor flows going in and out of the network. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 04:54:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0F0q-0004Uy-Qv; Wed, 03 Aug 2005 04:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0F0o-0004Ut-S0 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 04:54:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25816 for ; Wed, 3 Aug 2005 04:54:04 -0400 (EDT) Received: from srv0010.pine.nl ([213.156.9.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FXS-0004PT-CW for ipv6@ietf.org; Wed, 03 Aug 2005 05:27:51 -0400 Received: from localhost (localhost [127.0.0.1]) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id 4F003435B21; Wed, 3 Aug 2005 10:53:56 +0200 (CEST) Received: from srv0010.pine.nl ([127.0.0.1]) by localhost (srv0010.pine.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 65499-01-15; Wed, 3 Aug 2005 10:53:28 +0200 (CEST) Received: from [86.255.25.45] (open-25-45.ietf63.ietf.org [86.255.25.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id 7D52E4355EC; Wed, 3 Aug 2005 10:53:28 +0200 (CEST) In-Reply-To: <00d301c59775$141fbfc0$5207ff56@samsung70c651a> References: <200508021341.JAA19303@ietf.org> <00d301c59775$141fbfc0$5207ff56@samsung70c651a> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <523BE260-D6BE-4801-AA02-EFCD71F843D1@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 3 Aug 2005 10:53:29 +0200 To: Soohong Daniel Park X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-new at pine.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: M & O bit discussion today (Requirement 3) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 2-aug-2005, at 17:15, Soohong Daniel Park wrote: > 2) Other requirements to be considered ? As someone who gets called when the day-to-day admins can't figure it out, I feel it's important that all of this is as predictable as possible. That means that I want to know whether hosts are going to get addresses from a DHCPv6 server or just other configuration information. Waiting to see what the DHCPv6 server is in the mood for today makes me very uncomfortable. So what I'd like to require is that hosts only ask for and/or accept addresses when the right RA bits are set, and don't ask for addresses and reject them if they get them anyway while RAs indicate that DHCPv6 should only be used for other configuration. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 04:59:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0F5x-0006TW-DY; Wed, 03 Aug 2005 04:59:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0F5q-0006Qk-Et for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 04:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26131 for ; Wed, 3 Aug 2005 04:59:16 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FcU-0004cZ-8C for ipv6@ietf.org; Wed, 03 Aug 2005 05:33:03 -0400 Received: by rproxy.gmail.com with SMTP id r35so115199rna for ; Wed, 03 Aug 2005 01:59:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YhGmrRBkiKhQDJ9S8diSl9FDzT71JS1IPAAWY5QUI2v08qlLBqBWLnh7UMs1UoD3Lg7iEjW9OBmeJWyTMivZTvYCDZEs0BUTqyeQJ+YQcsQl/uzk9dENrjcXjQqJOdgo0VQgZ8RUGKEf6+2yh9wNgRkC7zhdL6xHKWa8wohL600= Received: by 10.38.74.7 with SMTP id w7mr241344rna; Wed, 03 Aug 2005 01:59:16 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Wed, 3 Aug 2005 01:59:16 -0700 (PDT) Message-ID: <10e14db20508030159391b8675@mail.gmail.com> Date: Wed, 3 Aug 2005 10:59:16 +0200 From: Syam Madanapalli To: Iljitsch van Beijnum In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200508021341.JAA19303@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Tony Hain Subject: Re: M & O bit discussion today X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >=20 > > I choose not to try to get to the mic, but on the debated > > requirement point > > 3; why is there a belief that the DHCP relay information is correctly > > configured if the simpler set of 2 bits is improperly configured? >=20 > I think a case can be made for the notion that most routers and most > networks don't implement the bits today, so seeing MO=3D=3D00 doesn't > really authoratively say there is no DHCP service, but just that the > routers operate in a default configuration. Does this mean that the current implementations always do the DHCPv6 irrespective of the bits? >=20 > So it would be useful to redefine MO=3D=3D00 to mean "no opinion" and > come up with a new value that indicates authoritative information > that DHCPv6 is unavailable and/or shouldn't be used. If we define the 00=3DNo Opinion, then we may need to use 11 to convey unavailability of DHCPv6, may not be good symantics. If we agree that we need to convey 'availability', 'unavailability' and=20 'no opinion; then how about the following combination M O 0 0 - DHCPv6 Not avaialble 0 1 - Only DHCP6v lite 1 0 - Full DHCPv6 1 1 - No opinion (router does not know if the DHCPv6 avaialble or= not) -Syam -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 05:20:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FPz-0002g3-CW; Wed, 03 Aug 2005 05:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FPw-0002fW-Us for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 05:20:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27486 for ; Wed, 3 Aug 2005 05:20:00 -0400 (EDT) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FwY-0005ZG-U1 for ipv6@ietf.org; Wed, 03 Aug 2005 05:53:48 -0400 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 1E9F4B8E3 for ; Wed, 3 Aug 2005 02:19:55 -0700 (PDT) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11279-02 for ; Wed, 3 Aug 2005 02:19:53 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [IPv6:3ffe:1200:3033:1:209:5bff:fe8e:6dd3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 78EFAB8A7 for ; Wed, 3 Aug 2005 02:19:53 -0700 (PDT) Received: from [86.255.24.221] (open-24-221.ietf63.ietf.org [86.255.24.221]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id j739QeP2028226 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 3 Aug 2005 02:26:42 -0700 Mime-Version: 1.0 (Apple Message framework v622) To: IPv6 WG Message-Id: <049facf3a8d227119e84635cd4bbbdc8@innovationslab.net> From: Brian Haberman Date: Wed, 3 Aug 2005 05:19:48 -0400 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: Call for RFC 2472 Implementation Reports X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1824090217==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1824090217== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-872184635; protocol="application/pkcs7-signature" --Apple-Mail-5-872184635 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit All, As mentioned during the IPv6 WG meeting, the chairs are soliciting implementation reports for IPv6 over PPP in support of moving the spec to Draft Standard. The following template should be used for submitting these implementation reports. The reports can be sent to the chairs and/or the mailing list. Implementation Report for RFC 2472 (IPv6 over PPP) ------------------------------------------------------------------------ 1. Implementation Name: 2. Submitter Name: 3. Submitter E-mail: 4. Code Origin: 5. Features Implemented: 6. Tested Interoperability by Feature: A. IPv6CP (Section 3) B. Interface Identifier Negotiation (Section 4.1) C. Stateless Auto-configuration (Section 5) Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-5-872184635 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODAzMDkxOTQ5WjAjBgkqhkiG9w0B CQQxFgQUNkEkZQ0kVy116mw1SlRj9r6JFLkweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAYRttLG+Ki9FSgpUDLvcAUEZ4T9v6GdN1bEPgjkWVWNht9DZNfcffATn4manPmo0ty4iP zCRhr3mOVtU6osv/rRsRis/FOif9N9squfSS9mXJxatoy2jiNmymC7p/x/RSn4YF3b6Jqi9IFuqO ZEpg56ZBzZzMFrPe8bLHhvqUklPsDy+ww9BZvyyQEr7/qv/bJgI7tFywy5ESfgb6ZX0df77LyLiy /vI6kkxcX9fLW7xQ/KJDvTfB3ZNVSdo6/SKO6ge9vK7tVXqhboBFlla0QB0IG4cBF7kaAnZXWStd Pb8Xz9cSp6LKNn8xHU+phI3r7JC4npjVNCyhu5yHu9i4HQAAAAAAAA== --Apple-Mail-5-872184635-- --===============1824090217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1824090217==-- From ipv6-bounces@ietf.org Wed Aug 03 05:20:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FQS-0002sF-J5; Wed, 03 Aug 2005 05:20:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FQQ-0002ph-Bf for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 05:20:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27510 for ; Wed, 3 Aug 2005 05:20:32 -0400 (EDT) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Fx4-0005Zz-1i for ipv6@ietf.org; Wed, 03 Aug 2005 05:54:19 -0400 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id F403FB97E for ; Wed, 3 Aug 2005 02:20:31 -0700 (PDT) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11279-02-2 for ; Wed, 3 Aug 2005 02:20:30 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [IPv6:3ffe:1200:3033:1:209:5bff:fe8e:6dd3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 44F79B900 for ; Wed, 3 Aug 2005 02:20:30 -0700 (PDT) Received: from [86.255.24.221] (open-24-221.ietf63.ietf.org [86.255.24.221]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id j739QeP3028226 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 3 Aug 2005 02:27:19 -0700 Mime-Version: 1.0 (Apple Message framework v622) To: IPv6 WG Message-Id: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> From: Brian Haberman Date: Wed, 3 Aug 2005 05:20:25 -0400 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: Call for RFC 3041 Implementation Reports X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064723474==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============2064723474== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-872221768; protocol="application/pkcs7-signature" --Apple-Mail-6-872221768 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit All, As mentioned during the IPv6 WG meeting, the chairs are soliciting implementation reports for IPv6 Privacy Addresses in support of moving the spec to Draft Standard. The following template should be used for submitting these implementation reports. The reports can be sent to the chairs and/or the mailing list. Implementation Report for RFC 3041 (IPv6 Privacy Addresses) ------------------------------------------------------------------------ 1. Implementation Name: 2. Submitter Name: 3. Submitter E-mail: 4. Code Origin: 5. Features Implemented: 6. Tested Interoperability by Feature: A. Lifetime Management (Section 3.4) B. DAD Operation (Section 3.2) Regards, Bob & Brian IPv6 WG co-chairs --Apple-Mail-6-872221768 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODAzMDkyMDI2WjAjBgkqhkiG9w0B CQQxFgQUM000HorKu/4w297wvKJfRYcj5n4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAWLz8BrgY8fVJNQuYxp49MXCCDuDpFYYCUZKIuUwngAJjwRiCDilO3xGwuqhWD+Ivyzh6 bP+L0TX9cyOGbo2+Af0bqzmM/81UJa4LJilCnt1W0NQ6HpsQrpti0zUV4bosfQfy7gNKUOQmQDHR vg3XNJ57Azdt69HgSdCRcXS4ggveJoRlHC67Gzg4Exw88Fi7vBp9OdFkC6XFOtrYCCzqZkAm4ryT G6MJ50Cn8nh4hv/S0DfBgQey/P3vff0d8PSZxGhfQC6j4TxjYdI0VTIYtPmVq+XgDVMSvvVOicnj gnGWJ5Hhb1uu59CCuhM1HECLRs5dSNebPOWwvka5U83RNAAAAAAAAA== --Apple-Mail-6-872221768-- --===============2064723474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============2064723474==-- From ipv6-bounces@ietf.org Wed Aug 03 05:44:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fnx-00024K-5u; Wed, 03 Aug 2005 05:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fnv-00024C-5H for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 05:44:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29967 for ; Wed, 3 Aug 2005 05:44:49 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GKY-0006lD-W7 for ipv6@ietf.org; Wed, 03 Aug 2005 06:18:36 -0400 Received: from eamrcnt770.exu.ericsson.se (mail1att.ericy.com. [138.85.133.17]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id j739ieJP020116; Wed, 3 Aug 2005 04:44:40 -0500 Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt770.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 36TRZ7FV; Wed, 3 Aug 2005 04:44:39 -0500 Received: from dhcp723-115.rnet.lmc.ericsson.se (dhcp723-115.rnet.lmc.ericsson.se [142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j739id6l017182; Wed, 3 Aug 2005 05:44:39 -0400 (EDT) Date: Wed, 3 Aug 2005 05:43:27 -0400 (EDT) X-Sybari-Trust: 8f543d37 03fe309d 8ebd3e08 00000139 From: Suresh Krishnan X-X-Sender: suresh@dhcp723-115.rnet.lmc.ericsson.se To: Tony Hain In-Reply-To: <200508021341.JAA19303@ietf.org> Message-ID: <8DA338857B4F404282EE2088005079EA046E41C5@eammlex037-nb.lmc.ericsson.se> References: <200508021341.JAA19303@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipv6@ietf.org Subject: Re: M & O bit discussion today X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Tony, > I choose not to try to get to the mic, but on the debated requirement > point > 3; why is there a belief that the DHCP relay information is correctly > configured if the simpler set of 2 bits is improperly configured? > > I agree that point 1 & 3 are in direct conflict and that 1 is the real > requirement. This is my real problem as I said at the mic. I personally like Requirement 1 more than requirement 3. If requirement 3 is absolute, we might as well have these flags removed altogether as the hosts do not care. Cheers Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 05:47:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fqg-0003Ig-JZ; Wed, 03 Aug 2005 05:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fqf-0003IE-2S for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 05:47:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00278 for ; Wed, 3 Aug 2005 05:47:38 -0400 (EDT) Received: from srv0010.pine.nl ([213.156.9.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GNI-0006sb-7l for ipv6@ietf.org; Wed, 03 Aug 2005 06:21:26 -0400 Received: from localhost (localhost [127.0.0.1]) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id D0E61435AD6; Wed, 3 Aug 2005 11:47:29 +0200 (CEST) Received: from srv0010.pine.nl ([127.0.0.1]) by localhost (srv0010.pine.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 67545-01-33; Wed, 3 Aug 2005 11:47:20 +0200 (CEST) Received: from [86.255.25.45] (open-25-45.ietf63.ietf.org [86.255.25.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by srv0010.pine.nl (Pine Digital Security Mailer [srv0010.pine.nl]) with ESMTP id 15FDF4356AE; Wed, 3 Aug 2005 11:47:20 +0200 (CEST) In-Reply-To: <8E296595B6471A4689555D5D725EBB217427B7@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB217427B7@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 3 Aug 2005 11:47:22 +0200 To: Bernie Volz (volz) X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-new at pine.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: remarks (RE M/O Bits & Requirement 3) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org [Unfortunately I don't have connectivity in my hotel, so belatedly...] On 2-aug-2005, at 18:20, Bernie Volz (volz) wrote: > I believe requirement 3 is incorrectly stated; I think the > discussion in > the past was to have M=0/O=0 mean that the node SHOULD NOT start > DHCPv6. > I believe it was just desired that it *NOT* be a MUST NOT. I don't think the question we need to answer is "SHOULD NOT" or "MUST NOT" do DHCPv6 when the bits are 00. I believe it's a given that some people are going to run DHCPv6 without bothering to change the RA bits. The real question is what happens out of the box. Consider the situation where a popular OS does DHCPv6 when MO==00 by default. Since hunting down each and every one of these hosts and reconfiguring them to NOT do DHCPv6 isn't feasible, this means we then live in a universe where there will always be DHCPv6 packet on all links everywhere. (Even if most other OSes don't do DHCPv6 with MO==00 by default.) I don't think this is compatible with any interpretation of the use of the bits. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0G9A-0005ge-IO; Wed, 03 Aug 2005 06:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0G98-0005gX-15 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01574 for ; Wed, 3 Aug 2005 06:06:43 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Gfn-0007oM-Aw for ipv6@ietf.org; Wed, 03 Aug 2005 06:40:31 -0400 Received: from pc6 (1Cust24.tnt28.lnd4.gbr.da.uu.net [62.188.156.24]) by galaxy.systems.pipex.net (Postfix) with SMTP id 7BD6CE0002EA; Wed, 3 Aug 2005 11:06:33 +0100 (BST) Message-ID: <01f401c5980a$7e300ba0$0601a8c0@pc6> From: "Tom Petch" To: "Eric Klein" , References: <42EF95DA.50503@eng.monash.edu.au> <42EFA40D.7070600@sun.com> <00b001c597fe$13236020$0401a8c0@mtc.ki.se> Date: Wed, 3 Aug 2005 11:05:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Eric Klein" To: Sent: Wednesday, August 03, 2005 9:36 AM Subject: Re: network/all-host discovery and flooding attacks. > Erik Nordmark wrote: > > > I think that might be a reasonable middle ground. It would still make it > > harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP > > access to a local agent on the link that provide this (with appropriate > > SNMP security) to allow remote management. > > > > Elsewhere I've run into the management need to find a particular host > > from knowing only its MAC address. The suggestion to have INVARP would > > help with that subproblem. > > I agree that the security issues here are great, and that there is a need in > the Management world for this feature. If you could limit this to an SNMP v3 > secure function and not a IPv6 function then maybe we could work this out > within the security concerns of all involved. But that is a different WG (I > think that the SNMP v3 WG was closed down last year) so I would be real > careful in how we proceed. > > Eric > SNMPv3 WG did indeed shut down, work accomplished. MIBs continue to appear, of course, and there is an isms WG which seeks to integrate the security of SNMPv3 with the security systems already in place in organisations. The current security model does include an element of discovery, it won't work without it, but by itself it is insecure. It is unclear what a future security model would have but currently discovery does not look possible with it. My personal experience is of seeing very little IPv6 SNMP. Yes there are address families to allow for the different formats but outside that, SNMP seems a very IPv4 world. Tom Petch -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:22:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GO8-0004wE-Kk; Wed, 03 Aug 2005 06:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GO6-0004w8-Cd for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:22:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02270 for ; Wed, 3 Aug 2005 06:22:11 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Guh-0008T1-O9 for ipv6@ietf.org; Wed, 03 Aug 2005 06:56:00 -0400 Received: from jurassic.eng.sun.com ([129.146.104.45]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j73AM8r3002059; Wed, 3 Aug 2005 04:22:08 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j73ALvHf227683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 3 Aug 2005 03:22:07 -0700 (PDT) Message-ID: <42F09AF0.2050100@sun.com> Date: Wed, 03 Aug 2005 03:22:40 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Klein References: <42EF95DA.50503@eng.monash.edu.au> <42EFA40D.7070600@sun.com> <00b001c597fe$13236020$0401a8c0@mtc.ki.se> In-Reply-To: <00b001c597fe$13236020$0401a8c0@mtc.ki.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Eric Klein wrote: > I agree that the security issues here are great, and that there is a need in > the Management world for this feature. If you could limit this to an SNMP v3 > secure function and not a IPv6 function then maybe we could work this out > within the security concerns of all involved. But that is a different WG (I > think that the SNMP v3 WG was closed down last year) so I would be real > careful in how we proceed. Even with a SNMP approach for *remote* access, one would need to define how the local SNMP agent would discover the nodes attached to the *local* link. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:33:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GYs-0002DW-UB; Wed, 03 Aug 2005 06:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GYq-0002DA-R9 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:33:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02881 for ; Wed, 3 Aug 2005 06:33:18 -0400 (EDT) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0H5U-0000VN-0c for ipv6@ietf.org; Wed, 03 Aug 2005 07:07:06 -0400 Received: (qmail 23311 invoked by uid 417); 3 Aug 2005 10:33:14 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 3 Aug 2005 10:33:14 -0000 Received: from mehr ([132.70.220.115]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 03 Aug 2005 04:33:13 -0600 Message-ID: <018c01c59816$b5c02c60$0401a8c0@mtc.ki.se> From: "Eric Klein" To: ipv6@ietf.org References: <42EF95DA.50503@eng.monash.edu.au> <42EFA40D.7070600@sun.com><00b001c597fe$13236020$0401a8c0@mtc.ki.se> <01f401c5980a$7e300ba0$0601a8c0@pc6> Date: Wed, 3 Aug 2005 13:32:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tom Petch wrote: > > > > > I think that might be a reasonable middle ground. It would still make it > > > harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP > > > access to a local agent on the link that provide this (with appropriate > > > SNMP security) to allow remote management. > > > > > > Elsewhere I've run into the management need to find a particular host > > > from knowing only its MAC address. The suggestion to have INVARP would > > > help with that subproblem. > > > > I agree that the security issues here are great, and that there is a need in > > the Management world for this feature. If you could limit this to an SNMP v3 > > secure function and not a IPv6 function then maybe we could work this out > > within the security concerns of all involved. But that is a different WG (I > > think that the SNMP v3 WG was closed down last year) so I would be real > > careful in how we proceed. > > SNMPv3 WG did indeed shut down, work accomplished. MIBs continue to appear, of > course, and there is an isms WG which seeks to integrate the security of SNMPv3 > with the security systems already in place in organisations. The current > security model does include an element of discovery, it won't work without it, > but by itself it is insecure. It is unclear what a future security model would > have but currently discovery does not look possible with it. Maybe we should bring in the security people to this issue. > > My personal experience is of seeing very little IPv6 SNMP. Yes there are > address families to allow for the different formats but outside that, SNMP seems > a very IPv4 world. As we move into an IPv4/v6 or all IPv6 world these will become more of an issue, as element managers and OSS/BSS systems will need this functionality. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:34:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GaR-0002jm-CU; Wed, 03 Aug 2005 06:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GaN-0002hj-OY for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:34:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03008 for ; Wed, 3 Aug 2005 06:34:53 -0400 (EDT) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0H73-0000YV-6w for ipv6@ietf.org; Wed, 03 Aug 2005 07:08:41 -0400 Received: (qmail 29453 invoked by uid 417); 3 Aug 2005 10:34:54 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 3 Aug 2005 10:34:54 -0000 Received: from mehr ([132.70.220.115]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 03 Aug 2005 04:34:53 -0600 Message-ID: <019001c59816$f165a4c0$0401a8c0@mtc.ki.se> From: "Eric Klein" To: ipv6@ietf.org References: <42EF95DA.50503@eng.monash.edu.au> <42EFA40D.7070600@sun.com><00b001c597fe$13236020$0401a8c0@mtc.ki.se> <42F09AF0.2050100@sun.com> Date: Wed, 3 Aug 2005 13:34:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: Re: network/all-host discovery and flooding attacks. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Erik Nordmark wrote: > > > I agree that the security issues here are great, and that there is a need in > > the Management world for this feature. If you could limit this to an SNMP v3 > > secure function and not a IPv6 function then maybe we could work this out > > within the security concerns of all involved. But that is a different WG (I > > think that the SNMP v3 WG was closed down last year) so I would be real > > careful in how we proceed. > > Even with a SNMP approach for *remote* access, one would need to define > how the local SNMP agent would discover the nodes attached to the > *local* link. Agreed. In the local network this will be a crucial requirement for network management, in the external one it would be dangerous as it could be used to map a network or for DOS attacks. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:35:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gab-0002o8-WB; Wed, 03 Aug 2005 06:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GaZ-0002n8-Hf for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:35:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03027 for ; Wed, 3 Aug 2005 06:35:05 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0H7E-0000YZ-2P for ipv6@ietf.org; Wed, 03 Aug 2005 07:08:53 -0400 Received: from eamrcnt770.exu.ericsson.se (mail1att.ericy.com. [138.85.133.17]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id j73AYtJx022951 for ; Wed, 3 Aug 2005 05:34:55 -0500 Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt770.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 36TRZ8TC; Wed, 3 Aug 2005 05:34:54 -0500 Received: from dhcp723-115.rnet.lmc.ericsson.se (dhcp723-115.rnet.lmc.ericsson.se [142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j73AYs6l018489 for ; Wed, 3 Aug 2005 06:34:54 -0400 (EDT) Date: Wed, 3 Aug 2005 06:33:42 -0400 (EDT) X-Sybari-Trust: 5c720916 03fe309d 8ebd3e08 00000139 From: Suresh Krishnan X-X-Sender: suresh@dhcp723-115.rnet.lmc.ericsson.se To: ipv6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: Elevation to Full Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Suresh Krishnan List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Folks, I think the node requirements document needs to be advanced as well before we should move the base specs to Full Standard as one cannot easily figure out what she/he should do to be IPv6 compliant. e.g. If I implement just RFC2460 and not RFC2461 and RFC2462 am I still compliant? Cheers Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:35:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gag-0002ru-EP; Wed, 03 Aug 2005 06:35:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gac-0002pH-SW for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:35:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03033 for ; Wed, 3 Aug 2005 06:35:08 -0400 (EDT) Received: from srv0001.pine.nl ([213.156.9.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0H7G-0000Ya-7s for ipv6@ietf.org; Wed, 03 Aug 2005 07:08:56 -0400 Received: from localhost (localhost [127.0.0.1]) by srv0001.pine.nl (Pine Digital Security Mailer [srv0001.pine.nl]) with ESMTP id C9214397090; Wed, 3 Aug 2005 12:34:56 +0200 (CEST) Received: from srv0001.pine.nl ([127.0.0.1]) by localhost (srv0001.pine.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31376-01-3; Wed, 3 Aug 2005 12:34:43 +0200 (CEST) Received: from [86.255.25.45] (open-25-45.ietf63.ietf.org [86.255.25.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by srv0001.pine.nl (Pine Digital Security Mailer [srv0001.pine.nl]) with ESMTP id 6CEB7396F72; Wed, 3 Aug 2005 12:34:43 +0200 (CEST) In-Reply-To: <10e14db20508030159391b8675@mail.gmail.com> References: <200508021341.JAA19303@ietf.org> <10e14db20508030159391b8675@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26EE79F9-4B78-46FA-BD5F-6F2950FE9D8E@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 3 Aug 2005 12:34:44 +0200 To: Syam Madanapalli X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-new at pine.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: M & O bit discussion today X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 3-aug-2005, at 10:59, Syam Madanapalli wrote: >> I think a case can be made for the notion that most routers and most >> networks don't implement the bits today, so seeing MO==00 doesn't >> really authoratively say there is no DHCP service, but just that the >> routers operate in a default configuration. > Does this mean that the current implementations always do the DHCPv6 > irrespective of the bits? I only know a limited number of DHCPv6 implementations (KAME, Cisco) but those don't consider the bits. Apparently, they assume the daemon is only run when the bits are set in some way, and/or when the daemon is run, DHCPv6 should be done period. >> So it would be useful to redefine MO==00 to mean "no opinion" and >> come up with a new value that indicates authoritative information >> that DHCPv6 is unavailable and/or shouldn't be used. > If we define the 00=No Opinion, then we may need to use 11 to convey > unavailability of DHCPv6, may not be good symantics. I agree that it's contrary to the existing definition of the bits, and it no longer allows considering either bit individually. Actually on rereading RFC 2462: In addition, when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well. It is not a valid configuration for a host to use stateful address autoconfiguration to request addresses only, without also accepting other configuration information. it seems that the "unused" bit combination would be MO==10. > If we agree that we need to convey 'availability', 'unavailability' > and > 'no opinion; then how about the following combination > M O > 0 0 - DHCPv6 Not avaialble > 0 1 - Only DHCP6v lite > 1 0 - Full DHCPv6 > 1 1 - No opinion (router does not know if the DHCPv6 > avaialble or not) This requires that routers are explicitly configured to allow DHCPv6. Personally, that doesn't bother me, but this goes against requirement 3 on Jinmei's now infamous list of three requirements. It's probably better to have a value that authoratively indicates that DHCPv6 MUST NOT be used rather than use the current 00 value that is present on all routers out of the box, so 00 can easily be interpreted as laziness rather than the desire to not run DHCPv6. Answering points brought up by others in other messages: requiring hosts to know which interfaces they should and shouldn't run DHCPv6 on by default seems very unattractive to me, to say the least. This doesn't allow for bridges between different network types and it also doesn't address the desire to avoid running DHCP for various reasons other than resource conservation. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:47:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GmT-0002Ou-M6; Wed, 03 Aug 2005 06:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GmQ-0002MB-Sf for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:47:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03975 for ; Wed, 3 Aug 2005 06:47:20 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0HJ5-0001Ak-7w for ipv6@ietf.org; Wed, 03 Aug 2005 07:21:08 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j73AlKqA019671 for ; Wed, 3 Aug 2005 11:47:20 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA17424 for ; Wed, 3 Aug 2005 11:47:02 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j73Al2Z17592 for ipv6@ietf.org; Wed, 3 Aug 2005 11:47:02 +0100 Date: Wed, 3 Aug 2005 11:47:02 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050803104702.GD16624@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <200508021341.JAA19303@ietf.org> <8DA338857B4F404282EE2088005079EA046E41C5@eammlex037-nb.lmc.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DA338857B4F404282EE2088005079EA046E41C5@eammlex037-nb.lmc.ericsson.se> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Re: M & O bit discussion today X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Aug 03, 2005 at 05:43:27AM -0400, Suresh Krishnan wrote: > Hi Tony, > > >I choose not to try to get to the mic, but on the debated requirement > >point > >3; why is there a belief that the DHCP relay information is correctly > >configured if the simpler set of 2 bits is improperly configured? > > > >I agree that point 1 & 3 are in direct conflict and that 1 is the real > >requirement. > > This is my real problem as I said at the mic. I personally like > Requirement 1 more than requirement 3. If requirement 3 is absolute, > we might as well have these flags removed altogether as the > hosts do not care. Yes, advance 1 and discard 3. Explore ramifications of 2 in dhc WG. -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 06:48:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gnz-0002gl-Lr; Wed, 03 Aug 2005 06:48:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gnx-0002gV-UP for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 06:48:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04059 for ; Wed, 3 Aug 2005 06:48:55 -0400 (EDT) Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0HKc-0001FV-F3 for ipv6@ietf.org; Wed, 03 Aug 2005 07:22:43 -0400 Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 7ACEBBAD2; Wed, 3 Aug 2005 03:48:55 -0700 (PDT) Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12286-02-5; Wed, 3 Aug 2005 03:48:53 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [IPv6:3ffe:1200:3033:1:209:5bff:fe8e:6dd3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DA5BCBAD7; Wed, 3 Aug 2005 03:48:53 -0700 (PDT) Received: from [86.255.24.221] (open-24-221.ietf63.ietf.org [86.255.24.221]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id j73AteP2028954 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 3 Aug 2005 03:55:43 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: Brian Haberman Date: Wed, 3 Aug 2005 06:48:44 -0400 To: Suresh Krishnan X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ipv6@ietf.org Subject: Re: Elevation to Full Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1149147068==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1149147068== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-877519948; protocol="application/pkcs7-signature" --Apple-Mail-2-877519948 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Suresh, On Aug 3, 2005, at 6:33, Suresh Krishnan wrote: > Hi Folks, > I think the node requirements document needs to be advanced as well > before we should move the base specs to Full Standard as one cannot > easily figure out what she/he should do to be IPv6 compliant. e.g. If > I implement just RFC2460 and not RFC2461 and RFC2462 am I still > compliant? > Just so everyone is aware, the node requirements spec has been in the RFC Editor's Queue for quite some time. It is held up on normative references to specs outside of the IPv6 WG control (security drafts). Regards, Brian --Apple-Mail-2-877519948 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODAzMTA0ODQ0WjAjBgkqhkiG9w0B CQQxFgQUncOUXE0rhUKjDio62v3jOefQiOAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAWqUBP9WSHssMnUk6sN+C7UdTMGIUJW3g+aLt8I1OvjFbF/gEHfUqlw7HcD0bP7DWMz3n XYynrQ3XOyMOovHGPaiItvLYT6ojLmHUAgk7HDQeereM7/l2qU43BBSsmOO99MDSBTED7LiWjlrK gUH9ymwoJSPI9ClIcA6OX1H1wNAM2wMitrI/b4cUTRb+tM70/IsUkv/p1UCAZdJneo5y4aC3U8Di Q9n1DlT9/YJEpCl0toitNruNnElxGC9h7mbx5ykAvoVdwBU32jh72WW8iwIs3gjblafHsDCnf/Wr iYuu9KyyNbiXx3uA+cfBb3CHXpw8sg1DnKwGFwc+oSDIUgAAAAAAAA== --Apple-Mail-2-877519948-- --===============1149147068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1149147068==-- From ipv6-bounces@ietf.org Wed Aug 03 07:22:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HKr-0004oz-S7; Wed, 03 Aug 2005 07:22:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HKq-0004or-6T for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 07:22:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05931 for ; Wed, 3 Aug 2005 07:22:53 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0HrU-0002lS-PD for ipv6@ietf.org; Wed, 03 Aug 2005 07:56:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j73BIvL7022617; Wed, 3 Aug 2005 14:18:59 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 14:22:47 +0300 Received: from l5131412.nokia.com ([172.25.154.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Aug 2005 14:22:47 +0300 Message-Id: <6.2.1.2.2.20050803041850.0257d548@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 03 Aug 2005 04:22:50 -0700 To: "Brian Haberman" From: Bob Hinden In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 03 Aug 2005 11:22:47.0718 (UTC) FILETIME=[AD32AC60:01C5981D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipv6@ietf.org, Suresh Krishnan Subject: Re: Elevation to Full Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>Hi Folks, >> I think the node requirements document needs to be advanced as well >> before we should move the base specs to Full Standard as one cannot >> easily figure out what she/he should do to be IPv6 compliant. e.g. If I >> implement just RFC2460 and not RFC2461 and RFC2462 am I still compliant? > >Just so everyone is aware, the node requirements spec has been in >the RFC Editor's Queue for quite some time. It is held up on >normative references to specs outside of the IPv6 WG control (security >drafts). Further, all of the normative references are now in the RFC-Editor queue so it's not waiting for some other work to be completed. Also, Node Requirements is going to be published with Informational status (e.g., it doesn't advance through the standards process). Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 07:33:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HUi-0000aV-GS; Wed, 03 Aug 2005 07:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HUh-0000aM-Dm for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 07:33:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06393 for ; Wed, 3 Aug 2005 07:33:05 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0I1L-0003MB-8y for ipv6@ietf.org; Wed, 03 Aug 2005 08:06:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j73BX2l1000821; Wed, 3 Aug 2005 14:33:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 14:32:58 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 14:32:58 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2005 14:32:57 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEABE@esebe100.NOE.Nokia.com> Thread-Topic: Elevation to Full Standard Thread-Index: AcWYF+1GKCZiE7+BT8C40ybiIPO7DAABwvxA To: , X-OriginalArrivalTime: 03 Aug 2005 11:32:58.0447 (UTC) FILETIME=[193885F0:01C5981F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Elevation to Full Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The Node Requirements is informative, so it doesn't advance. However, the document should be reved as appropriate to handle the issues you mention. John > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Suresh Krishnan > Sent: 03 August, 2005 13:34 > To: ipv6@ietf.org > Subject: Elevation to Full Standard >=20 >=20 > Hi Folks, > I think the node requirements document needs to be advanced as well = > before we should move the base specs to Full Standard as one cannot = easily=20 > figure out what she/he should do to be IPv6 compliant. e.g. If I = implement=20 > just RFC2460 and not RFC2461 and RFC2462 am I still compliant? >=20 > Cheers > Suresh >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 07:55:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Hqe-0003Fz-8I; Wed, 03 Aug 2005 07:55:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Hqc-0003Fr-Jr for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 07:55:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07723 for ; Wed, 3 Aug 2005 07:55:45 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0INH-0004KV-NV for ipv6@ietf.org; Wed, 03 Aug 2005 08:29:33 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j73BtZmp143804 for ; Wed, 3 Aug 2005 11:55:35 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j73BtZX4184662 for ; Wed, 3 Aug 2005 13:55:35 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j73BtYj3023836 for ; Wed, 3 Aug 2005 13:55:34 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j73BtYVe023826; Wed, 3 Aug 2005 13:55:34 +0200 Received: from zurich.ibm.com (sig-9-145-130-197.de.ibm.com [9.145.130.197]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA43810; Wed, 3 Aug 2005 13:55:33 +0200 Message-ID: <42F0B0B5.3030909@zurich.ibm.com> Date: Wed, 03 Aug 2005 13:55:33 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Suresh Krishnan References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Elevation to Full Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Suresh Krishnan wrote: > Hi Folks, > I think the node requirements document needs to be advanced as well > before we should move the base specs to Full Standard as one cannot > easily figure out what she/he should do to be IPv6 compliant. e.g. If I > implement just RFC2460 and not RFC2461 and RFC2462 am I still compliant? > > Cheers > Suresh > That isn't necessary. The node requirements draft is indeed the one that summarizes what you need to support, but it can refer equally well to a DS or a Standard document. It isn't a compliance document. What is more tricky is for a Standard to refer normatively "down" to a DS (or PS) - that is not normally allowed. If you think this is silly, please join the newtrk WG. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 08:09:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0I3d-0003F1-J9; Wed, 03 Aug 2005 08:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0I3b-0003Er-5V for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 08:09:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09194 for ; Wed, 3 Aug 2005 08:09:10 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0IaG-00059O-DV for ipv6@ietf.org; Wed, 03 Aug 2005 08:42:57 -0400 Received: by rproxy.gmail.com with SMTP id r35so136266rna for ; Wed, 03 Aug 2005 05:09:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aP+YEPt3VriMScZzLixYHtp42rYWxQiMfMeJRfA7Zmr/A69ffBWB1b5THYk62Wh2ILmAFHiAmN+A7Wp2FRqRDPuEc0z5CBboajCiHZB84klbjUp7zvrxBlCEN081tp9MrzxNz6o1lgO7AqWfxITxJp38Zni1YbV5zElO/SXXSsM= Received: by 10.38.76.73 with SMTP id y73mr304331rna; Wed, 03 Aug 2005 05:09:05 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Wed, 3 Aug 2005 05:09:05 -0700 (PDT) Message-ID: <10e14db2050803050929587f58@mail.gmail.com> Date: Wed, 3 Aug 2005 14:09:05 +0200 From: Syam Madanapalli To: Ted Lemon In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org, =?ISO-2022-JP?Q?JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= Subject: Re: [dhcwg] Re: a summary of M/O flags requirements X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >=20 > There was also some question in the past of what to do when the M and > O bits *change* between router advertisements. I can't remember who > brought it up. I don't recall seeing any resolution to this. > While secure RA sounds really neat, I suspect it will not be widely > usable on networks where ad-hoc connection is the norm (e.g., SOHO > and WiFi hotspots). If my gut feeling on this is correct, then how > we deal with the case where we get an RA with bad information really > is important. If a bad RA kills my IP connectivity, that's a big > problem. >=20 >=20 This can happen in the following cases. 1. Temporary unavaialbility of DHCPv6 server 2. Inconsistency of Routers configuration 3. Host changes the subnet and the new subnet may not support DHCPv6 The 3rd case can be handled gracefully as there is a link changes, so the bits will be reset. First two cases may be difficult to handle as the host does not know exactly the reason could be for the bits transition. Even if SEND is used, the inconsistency in router configuration can cause a problem. Nay be a host can do one of the two following. 1. Host keeps the state for all routers for the M/O bits: if the same route= r=20 is sending the bits with different values then host can accept the change. 2. When the host see the transition of bits 1 to 0 then it can check the=20 availability of DHCPv6 server by explicity sending a solicit (?) message to reconfirm the bits transition. -Syam Bits may go from 1 to 0 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 08:29:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0IMq-0007Fr-2N; Wed, 03 Aug 2005 08:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0IMo-0007Fh-3U for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 08:29:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10942 for ; Wed, 3 Aug 2005 08:29:00 -0400 (EDT) Message-Id: <200508031229.IAA10942@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ItS-0006Ao-8W for ipv6@ietf.org; Wed, 03 Aug 2005 09:02:48 -0400 Received: from eaglet (127.0.0.1:4736) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 3 Aug 2005 05:28:47 -0700 From: "Tony Hain" To: Date: Wed, 3 Aug 2005 14:28:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWYJLmPFimo6wRFQmSRNqXwtEjf1w== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Subject: potpourri X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Following up on the meeting session: As the IPv6 working group draws to a close the *only* proper action is to recommend to the IESG that all stable and eligible documents be progressed along the standards track. The IESG will do whatever it would anyway, so it does no good to try to fineness things by endless debates about last minute tweaks and the resulting potential to recycle in place. If there are minor clarifications to make, those should be done as independent documents in the context of addenda to the stable documents. IPv6 as the components which functionally replace RFC 791, 826, etc. is complete. Solving problems that are still unsolved in IPv4 remains as work for continuing or future working groups. That does not diminish the stability of the base documents, so they need to progress now. On the discussion about prefixes, we need to stop revisiting decisions. The IETF does need to make a statement because leaving this to the RIRs is equivalent to leaving the fox in charge of access to the chickens. The point I was trying to make at the mic is that there are vocal participants in the RIR community that are stuck in the conservation mindset and can't seem to do basic math. They will agree with Thomas, Geoff, & Lea's work that without doing anything IPv6 will be sufficient for a number of decades, but they seem to loose context when the simple change of the HD from .8 to .94 buys an order of magnitude which results in IPv6 being sufficient for a number of *centuries*. That timeframe is substantially long enough that it becomes difficult to grasp so without a good grasp of the lifetime their conservation mindset steps in claiming the need to curtail wasted bits at every turn. The whole /56 discussion is looking to take us from centuries to tens (or hundreds if combined with the HD change) of millennia. What they fail to recognize is that this is a zero sum game where we currently have a balance, and moving the efficiency toward allocation removes it from operational deployment models that are different from the past. It is extremely easy to overlook the fact that some deployment models don't currently exist because they can't under the constraints of current allocation policy. This leads to a false belief that they will not appear over the next several centuries because we have yet to see them, when the reality is that it is the limited perspective policies which insure they will not ever appear. The IETF has to take the position of broad vision here and flatly state that undue conservation is detrimental. The RIR members are basically a greedy bunch. For those who have forgotten history, the initial 64 bit proposal exceeded the IPv6 design requirements by 3 orders of magnitude. At the start of the dot com boom it appeared there would not be enough room for comfortable waste by the service providers in terms of hierarchy so the entire 64 bits was dedicated to routing. Removing the allocation needs of 10^15 hosts meant 'more than enough' was now 'more than more than enough', particularly in light of the bust and consolidation. Even so there are continuing complaints about the /64 boundary and demands to relax that constraint because in historical deployment terms that number of bits per subnet is a waste. Never mind the issue that at some point in the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit EUI's... Fundamentally the RIR members just don't like being told what to do. If left alone they will constrain network deployments to what has been done in the past. It is up to the IPv6 WG to set the bar to avoid the state where people are forced to work around the restrictive policies of a provider and/or LIR/RIR. Finally it takes extreme hubris to believe that IPv6 is 'THE' protocol for centuries or millennia to come. Technology moves on, and IPv6 will be replaced long before the pool is exhausted. Those who point to the phone system as an example conveniently overlook the rolling evolution that effectively reduces the window of applicability. While there may be pockets where things still work, in my experience equipment from 40 years ago is not compatible with the current network so that example should be measured in decades rather than centuries. Even the numbering has undergone periodic change, so claiming we know enough to recognize allocation waste centuries before the person with a bright new idea is born is the highest form of arrogance. The /64 decision provides more than 'more than enough' routing space, and the /48 decision allows flexibility at the site level without significant impact on the service provider's ability to waste bits themselves. Changing those values only makes it harder to innovate in the space of automated configuration of site networks and hosts, and really doesn't buy any useful time because we are talking about adding time to the point well beyond the useful lifetime of the protocol. As I said in draft-hain-prefix-consider-00.txt there may be business reasons to consider other lengths, but there are no technical reasons. We need to state that clearly before the IPv6 WG closes. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 08:44:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ibb-0005aG-Tw; Wed, 03 Aug 2005 08:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Iba-0005YZ-SA for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 08:44:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11889 for ; Wed, 3 Aug 2005 08:44:17 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx3.orcon.net.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0J8G-0006qE-8o for ipv6@ietf.org; Wed, 03 Aug 2005 09:18:05 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx3.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j73CkFo8016914 for ; Thu, 4 Aug 2005 00:46:15 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1E0IbB-0007Em-00 for ; Thu, 04 Aug 2005 00:43:53 +1200 Message-ID: <42F0BC09.3070105@coders.net> Date: Thu, 04 Aug 2005 00:43:53 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050730 X-Accept-Language: en-nz, en MIME-Version: 1.0 CC: IETF IPv6 Mailing List References: <200508021341.JAA19303@ietf.org> <00d301c59775$141fbfc0$5207ff56@samsung70c651a> <523BE260-D6BE-4801-AA02-EFCD71F843D1@muada.com> In-Reply-To: <523BE260-D6BE-4801-AA02-EFCD71F843D1@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1002/Wed Aug 3 22:29:36 2005 on dbmail-mx3.orcon.net.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: Re: M & O bit discussion today (Requirement 3) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Iljitsch van Beijnum wrote: > On 2-aug-2005, at 17:15, Soohong Daniel Park wrote: > >> 2) Other requirements to be considered ? > > As someone who gets called when the day-to-day admins can't figure it > out, I feel it's important that all of this is as predictable as > possible. That means that I want to know whether hosts are going to get > addresses from a DHCPv6 server or just other configuration information. > Waiting to see what the DHCPv6 server is in the mood for today makes me > very uncomfortable. What worries me more is machines going off and using some other random DHCPv6 server that some monkey has plugged into the network. Sure this situation shouldn't occur, but how many times have you seen it take a currently functioning network down? If a network is designed to not need dhcpv6, then having a client decide to do dhcpv6 can only end in pain and suffering. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 09:00:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ire-00067Y-Lh; Wed, 03 Aug 2005 09:00:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Irb-00066m-HG for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 09:00:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12963 for ; Wed, 3 Aug 2005 09:00:50 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JOH-0007fh-72 for ipv6@ietf.org; Wed, 03 Aug 2005 09:34:38 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j73Cus4B010081; Wed, 3 Aug 2005 15:56:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 16:00:48 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Aug 2005 16:00:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2005 16:00:47 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEACC@esebe100.NOE.Nokia.com> Thread-Topic: potpourri Thread-Index: AcWYJLmPFimo6wRFQmSRNqXwtEjf1wABltWQ To: , X-OriginalArrivalTime: 03 Aug 2005 13:00:48.0116 (UTC) FILETIME=[5E303340:01C5982B] X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: potpourri X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > As the IPv6 working group draws to a close the *only* proper action is = to > recommend to the IESG that all stable and eligible documents be = progressed > along the standards track. The IESG will do whatever it would anyway, = so it > does no good to try to fineness things by endless debates about last = minute > tweaks and the resulting potential to recycle in place. If there are = minor > clarifications to make, those should be done as independent documents = in the > context of addenda to the stable documents. IPv6 as the components = which > functionally replace RFC 791, 826, etc. is complete. Solving problems = that > are still unsolved in IPv4 remains as work for continuing or future = working > groups. That does not diminish the stability of the base documents, so = they > need to progress now. For what it's worth, I think Tony makes an excellent point. I think = that we've done good work in the IPv6 on developing & progressing these = documents, and we should not try to second guess what the IESG will or will not = say. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 09:05:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ivi-00071d-7l; Wed, 03 Aug 2005 09:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ivf-00070Y-Hb for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 09:05:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13329 for ; Wed, 3 Aug 2005 09:05:02 -0400 (EDT) Message-Id: <200508031305.JAA13329@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JSM-0007rb-82 for ipv6@ietf.org; Wed, 03 Aug 2005 09:38:50 -0400 Received: from eaglet (127.0.0.1:4822) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 3 Aug 2005 06:04:50 -0700 From: "Tony Hain" To: "'Greg Daley'" , Date: Wed, 3 Aug 2005 15:04:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42EF979B.9050505@eng.monash.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWXevdBp2TVgo3lS7+i2Uc4Wuub5AArdxnw X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: 'Fred Baker' Subject: RE: How ready is IPv6 - do we need to describe it? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is the charter of the v6ops WG. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Greg Daley > Sent: Tuesday, August 02, 2005 5:56 PM > To: ipv6@ietf.org > Subject: How ready is IPv6 - do we need to describe it? > > Hi, > > I was chatting with Keith Moore, and think that it may > help to provide guidance (a BCP) on which components > are stable and reliable for IPv6 deployment. > > Perhaps it could be seen as a wrap-up for the IPv6 WG. > > It may be possible to indicate the standard levels > at the time of writing, and indicate if there were > known remanant issues (or uncertainty) with a particular > protocol. > > This would give a clear idea of how far down the path > to usability the suite of v6 tools is, so that operators > can consider the state of the art before going ahead > with deployment. > > Does anyone have an opinion on if it would be helpful > or hurtful? > > Greg > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 09:22:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JCV-0007vf-TO; Wed, 03 Aug 2005 09:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JCT-0007v7-32 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 09:22:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15075 for ; Wed, 3 Aug 2005 09:22:23 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Jj8-0000Wv-Sw for ipv6@ietf.org; Wed, 03 Aug 2005 09:56:12 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j73DLlD00976; Wed, 3 Aug 2005 15:21:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j73DLmur016058; Wed, 3 Aug 2005 15:21:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508031321.j73DLmur016058@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Suresh Krishnan In-reply-to: Your message of Wed, 03 Aug 2005 06:33:42 EDT. Date: Wed, 03 Aug 2005 15:21:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: Elevation to Full Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: I think the node requirements document needs to be advanced as well before we should move the base specs to Full Standard as one cannot easily figure out what she/he should do to be IPv6 compliant. e.g. If I implement just RFC2460 and not RFC2461 and RFC2462 am I still compliant? => in this case IMHO you are not but for the more general issue the relevant body is more the IPv6 Forum and its IPv6 ready logo program. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 11:19:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0L1X-0004Pr-UR; Wed, 03 Aug 2005 11:19:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KKA-0007LV-L8 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 10:34:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22143 for ; Wed, 3 Aug 2005 10:34:24 -0400 (EDT) Received: from emsfhu1.fhu.disa.mil ([209.22.104.25] helo=emsfhu1.disanet.disa-u.mil) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kqr-0004KV-6L for ipv6@ietf.org; Wed, 03 Aug 2005 11:08:14 -0400 Received: by emsfhu1.fhu.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Aug 2005 07:34:18 -0700 Message-ID: <1A75D0719B277D4FAEDF114F6C4385980227721C@emsfhu1.fhu.disa.mil> From: "Smith, Shawn (Contractor)" To: "'Tony Hain '" , "''Greg Daley' '" , "'ipv6@ietf.org '" Date: Wed, 3 Aug 2005 07:34:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 03 Aug 2005 11:19:14 -0400 Cc: ''Fred Baker' ' Subject: RE: How ready is IPv6 - do we need to describe it? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org DoD would find this information helpful. Thanks, Shawn Smith INTEROP/JITC Ft. Huachuca, AZ 520-538-5220 -----Original Message----- From: Tony Hain To: 'Greg Daley'; ipv6@ietf.org Cc: 'Fred Baker' Sent: 8/3/2005 6:04 AM Subject: RE: How ready is IPv6 - do we need to describe it? This is the charter of the v6ops WG. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Greg Daley > Sent: Tuesday, August 02, 2005 5:56 PM > To: ipv6@ietf.org > Subject: How ready is IPv6 - do we need to describe it? > > Hi, > > I was chatting with Keith Moore, and think that it may > help to provide guidance (a BCP) on which components > are stable and reliable for IPv6 deployment. > > Perhaps it could be seen as a wrap-up for the IPv6 WG. > > It may be possible to indicate the standard levels > at the time of writing, and indicate if there were > known remanant issues (or uncertainty) with a particular > protocol. > > This would give a clear idea of how far down the path > to usability the suite of v6 tools is, so that operators > can consider the state of the art before going ahead > with deployment. > > Does anyone have an opinion on if it would be helpful > or hurtful? > > Greg > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 12:37:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MFh-0005JA-G9; Wed, 03 Aug 2005 12:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MFf-0005Iw-1W for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 12:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29622 for ; Wed, 3 Aug 2005 12:37:52 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MmM-000175-B2 for ipv6@ietf.org; Wed, 03 Aug 2005 13:11:43 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 08ECF1F2; Wed, 3 Aug 2005 12:37:38 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 12:37:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2005 12:37:35 -0400 Message-ID: <936A4045C332714F975800409DE09240BC2D30@tayexc14.americas.cpqcorp.net> Thread-Topic: potpourri Thread-Index: AcWYJLmPFimo6wRFQmSRNqXwtEjf1wAJF2Ug From: "Bound, Jim" To: "Tony Hain" , X-OriginalArrivalTime: 03 Aug 2005 16:37:37.0906 (UTC) FILETIME=[A8A09D20:01C59849] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: potpourri X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tony, you said it all, and I for one have no more to say on this and we should take your mail to heart and do exactly what you state. Regarding making statements about deployment all the IETF can do is make a statement of implementation state. Further on that mission is in process in the market and in process that also will do verification and one of them is the IPv6 Forum Logo program, for part of what is required, and that is going to be expanded. This will support equally both government and industry and world wide. thanks for your time to type all this in and thoughts, /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Tony Hain > Sent: Wednesday, August 03, 2005 8:29 AM > To: ipv6@ietf.org > Subject: potpourri >=20 > Following up on the meeting session: >=20 > As the IPv6 working group draws to a close the *only* proper=20 > action is to > recommend to the IESG that all stable and eligible documents=20 > be progressed > along the standards track. The IESG will do whatever it would=20 > anyway, so it > does no good to try to fineness things by endless debates=20 > about last minute > tweaks and the resulting potential to recycle in place. If=20 > there are minor > clarifications to make, those should be done as independent=20 > documents in the > context of addenda to the stable documents. IPv6 as the=20 > components which > functionally replace RFC 791, 826, etc. is complete. Solving=20 > problems that > are still unsolved in IPv4 remains as work for continuing or=20 > future working > groups. That does not diminish the stability of the base=20 > documents, so they > need to progress now. >=20 > On the discussion about prefixes, we need to stop revisiting=20 > decisions. The > IETF does need to make a statement because leaving this to the RIRs is > equivalent to leaving the fox in charge of access to the=20 > chickens. The point > I was trying to make at the mic is that there are vocal=20 > participants in the > RIR community that are stuck in the conservation mindset and=20 > can't seem to > do basic math. They will agree with Thomas, Geoff, & Lea's=20 > work that without > doing anything IPv6 will be sufficient for a number of=20 > decades, but they > seem to loose context when the simple change of the HD from=20 > .8 to .94 buys > an order of magnitude which results in IPv6 being sufficient=20 > for a number of > *centuries*. That timeframe is substantially long enough that=20 > it becomes > difficult to grasp so without a good grasp of the lifetime their > conservation mindset steps in claiming the need to curtail=20 > wasted bits at > every turn. The whole /56 discussion is looking to take us=20 > from centuries to > tens (or hundreds if combined with the HD change) of=20 > millennia. What they > fail to recognize is that this is a zero sum game where we=20 > currently have a > balance, and moving the efficiency toward allocation removes it from > operational deployment models that are different from the past. It is > extremely easy to overlook the fact that some deployment models don't > currently exist because they can't under the constraints of current > allocation policy. This leads to a false belief that they=20 > will not appear > over the next several centuries because we have yet to see=20 > them, when the > reality is that it is the limited perspective policies which=20 > insure they > will not ever appear. The IETF has to take the position of=20 > broad vision here > and flatly state that undue conservation is detrimental. >=20 > The RIR members are basically a greedy bunch. For those who=20 > have forgotten > history, the initial 64 bit proposal exceeded the IPv6 design=20 > requirements > by 3 orders of magnitude. At the start of the dot com boom it=20 > appeared there > would not be enough room for comfortable waste by the service=20 > providers in > terms of hierarchy so the entire 64 bits was dedicated to=20 > routing. Removing > the allocation needs of 10^15 hosts meant 'more than enough'=20 > was now 'more > than more than enough', particularly in light of the bust and=20 > consolidation. > Even so there are continuing complaints about the /64=20 > boundary and demands > to relax that constraint because in historical deployment=20 > terms that number > of bits per subnet is a waste. Never mind the issue that at=20 > some point in > the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit > EUI's... Fundamentally the RIR members just don't like being=20 > told what to > do. If left alone they will constrain network deployments to=20 > what has been > done in the past. It is up to the IPv6 WG to set the bar to=20 > avoid the state > where people are forced to work around the restrictive policies of a > provider and/or LIR/RIR. >=20 > Finally it takes extreme hubris to believe that IPv6 is 'THE'=20 > protocol for > centuries or millennia to come. Technology moves on, and IPv6 will be > replaced long before the pool is exhausted. Those who point=20 > to the phone > system as an example conveniently overlook the rolling evolution that > effectively reduces the window of applicability. While there=20 > may be pockets > where things still work, in my experience equipment from 40=20 > years ago is not > compatible with the current network so that example should be=20 > measured in > decades rather than centuries. Even the numbering has=20 > undergone periodic > change, so claiming we know enough to recognize allocation=20 > waste centuries > before the person with a bright new idea is born is the=20 > highest form of > arrogance. The /64 decision provides more than 'more than=20 > enough' routing > space, and the /48 decision allows flexibility at the site=20 > level without > significant impact on the service provider's ability to waste bits > themselves. Changing those values only makes it harder to=20 > innovate in the > space of automated configuration of site networks and hosts,=20 > and really > doesn't buy any useful time because we are talking about=20 > adding time to the > point well beyond the useful lifetime of the protocol. As I said in > draft-hain-prefix-consider-00.txt there may be business=20 > reasons to consider > other lengths, but there are no technical reasons. We need to=20 > state that > clearly before the IPv6 WG closes. >=20 > Tony >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 13:06:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MhU-000410-52; Wed, 03 Aug 2005 13:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MhS-00040v-V1 for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 13:06:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01296 for ; Wed, 3 Aug 2005 13:06:34 -0400 (EDT) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0NE6-0002Nd-SZ for ipv6@ietf.org; Wed, 03 Aug 2005 13:40:26 -0400 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Wed, 3 Aug 2005 17:06:32 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 3 Aug 2005 17:06:20 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2005 12:05:07 -0500 Message-ID: <041052AD735329479241C23E0813EB7E9EC87D@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Thread-Topic: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt Thread-Index: AcWX/e74Qgc3YlU8QjiyYihZOxfriQAA90NwABKoBhA= From: "Pashby, Ronald W CTR NSWCDD-B35" To: "Christian Huitema" , "Mark Smith" X-OriginalArrivalTime: 03 Aug 2005 17:05:07.0908 (UTC) FILETIME=[801AF040:01C5984D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org One assumption that is being made is that all hosts are trying to = communicate through a router. There are many networks that hosts only = talk to each other. Looking at ND tables or flows in a router is not = viable for these networks. True network discovery like security, relies on multiple mechanism. Not = one mechanism fits all. Active discovery is one of the key elements. = Passive monitoring (e.g. ND tables, MLD joins, DAD monitoring) is = another.=20 Some network administrators may determine that responses to all-hosts = ping is reasonable, others may not. Having all hosts contain the code = for responding gives the network administrators the choice. Without it, = they have no choice. The same is true for Inverse ND. Requiring that it be implemented gives = them the choice to use it or disable it. -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Wednesday, August 03, 2005 4:07 To: Mark Smith; Pashby, Ronald W CTR NSWCDD-B35 Cc: ipv6@ietf.org Subject: RE: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt > Only if they respond to the multicast echo request. Reality check: by default, host firewalls drop incoming echo requests. An explicit design goal of these firewalls is to make the host "stealthy", i.e. make sure the host is only detected by parties with which the host decide to communicate. I don't believe that polling protocols can reliably provide inventory. If you really want inventory, you probably will have better luck with a layer 2 access control protocol (802.1x), or by using a router based tool to monitor flows going in and out of the network. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 13:21:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Mvw-0002KT-AA; Wed, 03 Aug 2005 13:21:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Mvt-0002Jh-RR for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 13:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02017 for ; Wed, 3 Aug 2005 13:21:30 -0400 (EDT) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0NSa-0002z8-HP for ipv6@ietf.org; Wed, 03 Aug 2005 13:55:22 -0400 Received: (qmail 7441 invoked by uid 417); 3 Aug 2005 17:21:24 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 3 Aug 2005 17:21:24 -0000 Received: from mehr ([132.70.220.115]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 03 Aug 2005 11:21:22 -0600 Message-ID: <024801c5984f$b10d3bc0$0401a8c0@mtc.ki.se> From: "Eric Klein" To: "Pashby, Ronald W CTR NSWCDD-B35" , "Christian Huitema" , "Mark Smith" References: <041052AD735329479241C23E0813EB7E9EC87D@NAEAMILLEX05VA.nadsusea.nads.navy.mil> Date: Wed, 3 Aug 2005 20:20:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Ronald Pashby wrote > One assumption that is being made is that all hosts are trying to communicate through a > router. There are many networks that hosts only talk to each other. Looking at ND tables or > flows in a router is not viable for these networks. This is a good point, just look at the percentage of networked computers out there running MS Windows (not to mention the proposed future of dish washers, and other home appliances) and they all have a "Network Neighborhood" option which will try to identify other computers either by name or IP. In these cases a simple switch or hub could be used. Security inside the firewall is of less concern, but should still be a consideration here. Eric -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 03 17:58:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0RFr-0004aZ-AG; Wed, 03 Aug 2005 17:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0RFo-0004aU-GR for ipv6@megatron.ietf.org; Wed, 03 Aug 2005 17:58:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21309 for ; Wed, 3 Aug 2005 17:58:22 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0RmX-0006xL-Ut for ipv6@ietf.org; Wed, 03 Aug 2005 18:32:16 -0400 Received: from impact.jinmei.org (unknown [2001:688:ffff:20:ed6b:53db:90b2:3c69]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0958E1521D; Thu, 4 Aug 2005 06:57:54 +0900 (JST) Date: Thu, 04 Aug 2005 06:57:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Srinivas Goud In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org Subject: Re: IPv6 Final Destination Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 3 Aug 2005 13:10:38 +0530, >>>>> Srinivas Goud said: > Is Final Destination Option (just before upper layer protocol), mutable or > immutable? Whether an destination (or hop-by-hop) option is mutable is defined per-option basis. It is irrelevant from the position of the options header containing each particular option (e.g. just before upper layer protocol). See RFC2460 for more details. So, > Can I assume that Destination Options inside AH (before AH) are mutable and > Destination Option outside AH (after AH) as Immutable? No, you can't. You need to examine the third-highest-order bit of each option, regardless of the header position. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 01:09:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Xyl-0006Xb-D1; Thu, 04 Aug 2005 01:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Xyi-0006XO-PP for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 01:09:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08635 for ; Thu, 4 Aug 2005 01:09:12 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0YVV-0004hP-Ox for ipv6@ietf.org; Thu, 04 Aug 2005 01:43:08 -0400 Received: by wproxy.gmail.com with SMTP id 68so332053wri for ; Wed, 03 Aug 2005 22:09:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Ativ/Jf8PARPbM1KeVu3CvLEwauengkioGGrbls/hxAwdi5nCEmaZs5MYaYfFHjSipEdYGT5RmVCXWmr74umFVNGlHrmOyhQMIi2KPd239y+mzIr63N7k6MjyscG5ne2V6NmLUD95TiiUxZg3cTVkTSj1IlkqPJpby926scmbP8= Received: by 10.54.5.66 with SMTP id 66mr1197496wre; Wed, 03 Aug 2005 22:09:00 -0700 (PDT) Received: by 10.54.96.9 with HTTP; Wed, 3 Aug 2005 22:09:00 -0700 (PDT) Message-ID: Date: Thu, 4 Aug 2005 10:39:00 +0530 From: Srinivas Goud To: =?ISO-2022-JP?Q?JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= In-Reply-To: Mime-Version: 1.0 References: X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ipv6@ietf.org Subject: Re: IPv6 Final Destination Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Srinivas Goud List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0192355531==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0192355531== Content-Type: multipart/alternative; boundary="----=_Part_3047_72985.1123132140805" ------=_Part_3047_72985.1123132140805 Content-Type: text/plain; charset=ISO-2022-JP Content-Disposition: inline Content-Transfer-Encoding: 7bit I do agree with your points, but if you loot at rfc3775, it says that " The use of IPsec Authentication Header (AH) for the Home Address option is not required, except that if the IPv6 header of a packet is covered by AH, then the authentication MUST also cover the Home Address option; this coverage is achieved automatically by the definition of the Option Type code for the Home Address option, since it indicates that the data within the option cannot change en route to the packet's final destination, and thus the option is included in the AH computation." from the above, it is satisfactory that final destination option cannot be mutable. any opinions? Thanks, Srinivas. On 8/4/05, JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Wed, 3 Aug 2005 13:10:38 +0530, > >>>>> Srinivas Goud said: > > > Is Final Destination Option (just before upper layer protocol), mutable > or > > immutable? > > Whether an destination (or hop-by-hop) option is mutable is defined > per-option basis. It is irrelevant from the position of the options > header containing each particular option (e.g. just before upper layer > protocol). See RFC2460 for more details. > > So, > > > Can I assume that Destination Options inside AH (before AH) are mutable > and > > Destination Option outside AH (after AH) as Immutable? > > No, you can't. You need to examine the third-highest-order bit of > each option, regardless of the header position. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > ------=_Part_3047_72985.1123132140805 Content-Type: text/html; charset=ISO-2022-JP Content-Disposition: inline Content-Transfer-Encoding: 7bit
I do agree with your points, but if you loot at rfc3775, it says that

" The use of IPsec Authentication Header (AH) for the Home Address option is not required, except that if the IPv6 header of a packet is covered by AH, then the authentication MUST also cover the Home Address option; this coverage is achieved automatically by the definition of the Option Type code for the Home Address option, since it indicates that the data within the option cannot change en route to the packet's final destination, and thus the option is included in the AH computation."

from the above, it is satisfactory that final destination option cannot be mutable.
any opinions?

Thanks,
Srinivas.


On 8/4/05, JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp> wrote:
>>>>> On Wed, 3 Aug 2005 13:10:38 +0530,
>>>>> Srinivas Goud <cnugoud@gmail.com> said:

> Is Final Destination Option (just before upper layer protocol), mutable or
> immutable?

Whether an destination (or hop-by-hop) option is mutable is defined
per-option basis.  It is irrelevant from the position of the options
header containing each particular option (e.g. just before upper layer
protocol).  See RFC2460 for more details.

So,

> Can I assume that Destination Options inside AH (before AH) are mutable and
> Destination Option outside AH (after AH) as Immutable?

No, you can't.  You need to examine the third-highest-order bit of
each option, regardless of the header position.

                                        JINMEI, Tatuya
                                        Communication Platform Lab.
                                        Corporate R&D Center, Toshiba Corp.
                                        jinmei@isl.rdc.toshiba.co.jp



------=_Part_3047_72985.1123132140805-- --===============0192355531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0192355531==-- From ipv6-bounces@ietf.org Thu Aug 04 01:23:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0YCS-0003Rr-KO; Thu, 04 Aug 2005 01:23:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0YCP-0003Qx-KH for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 01:23:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09190 for ; Thu, 4 Aug 2005 01:23:20 -0400 (EDT) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0YjD-00059f-Sr for ipv6@ietf.org; Thu, 04 Aug 2005 01:57:17 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 04 Aug 2005 10:56:38 -0700 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j745MpbO012289 for ; Thu, 4 Aug 2005 05:23:02 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 10:52:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Aug 2005 10:52:50 +0530 Message-ID: <9E2962464AC4BD4E9CC38436D1F7789C2D98BF@xmb-blr-416.apac.cisco.com> Thread-Topic: IPv6 Service Discovery Thread-Index: AcWYtI7jzKPFZElIS0uy/+aieOKo9Q== From: "Abhijit Chaudhary \(abchaudh\)" To: X-OriginalArrivalTime: 04 Aug 2005 05:22:52.0477 (UTC) FILETIME=[8FD826D0:01C598B4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Subject: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574298851==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1574298851== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C598B4.8FC56CD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C598B4.8FC56CD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have question regarding IPv6 auto service discovery.=20 =20 Suppose a IPv6 Mobile Host comes and joins a network. Using Stateful or Stateless Address Configuration mentioned in ICMPv6 Router Advertisement message it gets a IPv6 address.=20 But if the mobile host want to know the nearest printer IP address or the proxy address or DNS server address (i.e, IP address of Responder mentioned in draft-ietf-ipngwg-icmp-name-lookups-12.txt). Is there any draft or RFC that talks about a procedure to get information about Server providing application Service for IPv6? =20 If not, I am of the impression that we can add a new option to Router Advertisement message called "Application Service Discovery Proxy". This option will contain the IPv6 address and Link-Layer address of the "Application Service Discovery Proxy". This proxy will contain all the information of the available application service in the network and the corresponding servers. The new option will look as below: =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address of Application Service Discovery Proxy | + | | +++++++++++++++++++++++++++++++++++++++++++++++ | ~ Link-Layer Address of Service Discovery Proxy | =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 The Message Exchange is described below: =20 1) Router Advertisement will contain the Application Service Discovery Proxy Option "Router Advertisement with Application Service Discovery Proxy Option" Router ------------------------------------------------------------------------ ---------------------------------------------------------> Host =20 2) Host gets the Address of the Application Service Discovery Proxy and stores it. Suppose, the host wants printing service, it uses some protocol (maybe UDP or XML over HTTP or ICMPv6) to discover services from the Application Service Discovery Proxy. For Printing service the message as below: "Give me printer service address"=20 1. Host ------------------------------------------------------------------------ ----------------> Application Service Discovery Proxy=20 =20 =20 "Printer IPv6 address =3D x, Printer LL address =3D y" 2. Application Service Discovery Proxy ------------------------------------------------------------------------ ---------------------------> Host =20 "Sends data to be printed"=20 3. Host -----------------------------------------------------------------------> Printer =20 Let me know what you guys feel about it. =20 Thanks, - Abhijit ------_=_NextPart_001_01C598B4.8FC56CD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
I have = question=20 regarding IPv6 auto service discovery. 
 
Suppose a IPv6=20 Mobile Host comes and joins a network. Using Stateful or Stateless = Address=20 Configuration mentioned in ICMPv6 Router  Advertisement message it = gets a=20 IPv6 address.
But if=20 the mobile host want to know the nearest printer IP address or the = proxy=20 address or DNS server address (i.e, IP address of Responder =  mentioned=20 in draft-ietf-ipngwg-icmp-name-lookups-12.txt).
Is there any draft or RFC that talks about a=20 procedure to get information about Server providing application = Service for=20 IPv6?
 
If not, I am of the impression that we can = add a new=20 option to Router  Advertisement message called "Application Service = Discovery Proxy". This option will contain the IPv6 address and = Link-Layer=20 address of the "Application Service Discovery Proxy". This proxy=20 will contain all the information of the available application = service in=20 the network and the corresponding servers. The new option will look = as=20 below:
 
      +-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  &n= bsp;  =20 |     = Type        =20 |   =20 Length           &= nbsp;=20 |           =20 Reserved           = ;          =20 | 
     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 |           IPv6 = Address of=20 Application  Service Discovery = Proxy      =20   |
     =20 +            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =          =20 |
     =20 |  +++++++++++++++++++++++++++++++++++++++++++++++=20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;
     =20 ~         Link-Layer Address=20 of  Service Discovery=20 Proxy           &n= bsp;      |   
 &nbs= p;   =20 |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =            =20 |
     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>
 
The Message Exchange is described=20 below:
 
1) Router Advertisement will contain the = Application=20 Service Discovery Proxy Option
       &nbs= p;            = ;            =  =20 "Router Advertisement with Application Service Discovery Proxy=20 Option"
       &nbs= p;        =20 Router =20 -------------------------------------------------------------------------= -------------------------------------------------------->=20 Host
 
2) Host gets the Address of the Application = Service=20 Discovery Proxy and stores it. Suppose, the host = wants printing=20 service, it uses some protocol (maybe UDP or XML over HTTP or ICMPv6) to = discover services from the Application Service Discovery=20 Proxy.
    For Printing service the = message as=20 below:
       &nbs= p;            = ;            =        =20 "Give me printer service address"
       &nbs= p;   1.    =20 Host=20 -------------------------------------------------------------------------= --------------->  Application=20 Service Discovery Proxy
 
       &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;         =20 "Printer IPv6 address =3D x, Printer LL address =3D = y"
       &nbs= p;   2.    =20 Application Service Discovery Proxy=20 -------------------------------------------------------------------------= -------------------------->=20 Host
 
       &nbs= p;            = ;            =            "Sends = data to be printed"
       &nbs= p;   3.     Host=20 -----------------------------------------------------------------------&g= t;=20 Printer
 
Let me know what you guys feel about=20 it.
 
Thanks,
- = Abhijit
------_=_NextPart_001_01C598B4.8FC56CD4-- --===============1574298851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1574298851==-- From ipv6-bounces@ietf.org Thu Aug 04 01:44:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0YWU-0001V8-AX; Thu, 04 Aug 2005 01:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0YWR-0001Ux-Ry for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 01:44:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09915 for ; Thu, 4 Aug 2005 01:44:02 -0400 (EDT) Received: from smta06.mail.ozemail.net ([203.103.165.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Z3F-0005sJ-Hl for ipv6@ietf.org; Thu, 04 Aug 2005 02:17:59 -0400 Received: from ubu.nosense.org ([210.84.239.70]) by smta06.mail.ozemail.net with ESMTP id <20050804054342.RDWG13841.smta06.mail.ozemail.net@ubu.nosense.org>; Thu, 4 Aug 2005 05:43:42 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 8A92B62B15; Thu, 4 Aug 2005 15:13:39 +0930 (CST) Date: Thu, 4 Aug 2005 15:13:39 +0930 From: Mark Smith To: "Abhijit Chaudhary (abchaudh)" Message-Id: <20050804151339.5fb252f0.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <9E2962464AC4BD4E9CC38436D1F7789C2D98BF@xmb-blr-416.apac.cisco.com> References: <9E2962464AC4BD4E9CC38436D1F7789C2D98BF@xmb-blr-416.apac.cisco.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Abhijit, I don't know all that much about how it operates however, I think that is what "SLP - Service Location Protocol" is designed for. From RFC2608 - " The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration." I don't know enough about it to say whether it allows for or needs to be updated to support IPv6. On a related note, I'd be curious to know if anybody is updating NetBIOS over IP / CIFS to support IPv6. I'd think that NetBIOS / CIFS file and print sharing probably carries more data on a daily basis than any other IPv4 carried protocol. Maybe that is one cause for people not introducing IPv6 to their enterprise networks - their most commonly used application protocol isn't supported over it. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 02:37:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZLo-0001c5-Qm; Thu, 04 Aug 2005 02:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZLm-0001c0-E1 for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 02:37:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04027 for ; Thu, 4 Aug 2005 02:37:05 -0400 (EDT) Received: from yue.linux-ipv6.org ([203.178.140.15] helo=yue.st-paulia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ZsZ-0007tP-Vf for ipv6@ietf.org; Thu, 04 Aug 2005 03:11:02 -0400 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 10A7933CC2; Thu, 4 Aug 2005 15:37:58 +0900 (JST) Date: Thu, 04 Aug 2005 08:37:50 +0200 (CEST) Message-Id: <20050804.083750.45351377.yoshfuji@linux-ipv6.org> To: cnugoud@gmail.com From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI/WIDE Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: yoshfuji@linux-ipv6.org, ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: IPv6 Final Destination Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In article (at Thu, 4 Aug 2005 10:39:00 +0530), Srinivas Goud says: > I do agree with your points, but if you loot at rfc3775, it says that > > " The use of IPsec Authentication Header (AH) for the Home Address option is > not required, except that if the IPv6 header of a packet is covered by AH, > then the authentication MUST also cover the Home Address option; this > coverage is achieved automatically by the definition of the Option Type code > for the Home Address option, since it indicates that the data within the > option cannot change en route to the packet's final destination, and thus > the option is included in the AH computation." > > from the above, it is satisfactory that final destination option cannot be > mutable. > any opinions? No. It is only a instance of destination options. Because it is possible to have other destination option(s), you cannot assume that "final" destination option is not mutable just by its position. --yoshfuji -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 02:48:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZWz-0005pp-EL; Thu, 04 Aug 2005 02:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZWu-0005nB-Vi for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 02:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04779 for ; Thu, 4 Aug 2005 02:48:35 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0a3k-0008MF-0S for ipv6@ietf.org; Thu, 04 Aug 2005 03:22:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2005 23:48:26 -0700 X-IronPort-AV: i="3.95,166,1120460400"; d="scan'208"; a="328853574:sNHT30834106" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j746mKQM029195; Wed, 3 Aug 2005 23:48:21 -0700 (PDT) Received: from [86.255.29.158] (ams-clip-vpn-dhcp4378.cisco.com [10.61.81.25]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j746jXOk015701; Wed, 3 Aug 2005 23:45:43 -0700 In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CEACC@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D6CEACC@esebe100.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C611E91-B7DB-4294-B767-60BBA8046A1A@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 4 Aug 2005 07:23:24 +0200 To: john.loughney@nokia.com X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=1382; t=1123137943; x=1123570143; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20potpourri| From:Fred=20Baker=20| Date:Thu,=204=20Aug=202005=2007=3A23=3A24=20+0200| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=dYf+E8WVRixyM2FxSTKXNbIoAbVlmA+OBxXh4dG14ZJ8PouKoYxjlfqq6qgKVz4CB+wQcDTp DK5p6soz2oAWgW/SrvkKViZBgYLjizwgD1Kz7yQ5eU4DJa/l+8KkLKOnrsZ0K4leJ4+OxjpXT+6 mheYDwfscau4/CXX7yAZDUYU= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, alh-ietf@tndh.net Subject: Re: potpourri X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org more to the point, the WG should change documents if they need to be changed, not if they feel someone else will worry that they need to be changed. The WG should send the *right* docs to the IESG, and presumably this is the set that it now has. On Aug 3, 2005, at 3:00 PM, john.loughney@nokia.com wrote: >> As the IPv6 working group draws to a close the *only* proper >> action is to >> recommend to the IESG that all stable and eligible documents be >> progressed >> along the standards track. The IESG will do whatever it would >> anyway, so it >> does no good to try to fineness things by endless debates about >> last minute >> tweaks and the resulting potential to recycle in place. If there >> are minor >> clarifications to make, those should be done as independent >> documents in the >> context of addenda to the stable documents. IPv6 as the components >> which >> functionally replace RFC 791, 826, etc. is complete. Solving >> problems that >> are still unsolved in IPv4 remains as work for continuing or >> future working >> groups. That does not diminish the stability of the base >> documents, so they >> need to progress now. >> > > For what it's worth, I think Tony makes an excellent point. I > think that > we've done good work in the IPv6 on developing & progressing these > documents, > and we should not try to second guess what the IESG will or will > not say. > > > John > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 02:49:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZXX-0005tY-SC; Thu, 04 Aug 2005 02:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZXV-0005tL-6w for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 02:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04794 for ; Thu, 4 Aug 2005 02:49:07 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0a4F-0008Mj-Uj for ipv6@ietf.org; Thu, 04 Aug 2005 03:23:05 -0400 Message-ID: <0ed801c598c0$9717cf70$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Abhijit Chaudhary (abchaudh)" , References: <9E2962464AC4BD4E9CC38436D1F7789C2D98BF@xmb-blr-416.apac.cisco.com> Date: Wed, 3 Aug 2005 23:48:57 -0700 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Cc: Subject: Re: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1971757042==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1971757042== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0ED5_01C59885.EA1CDE80" This is a multi-part message in MIME format. ------=_NextPart_000_0ED5_01C59885.EA1CDE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Check RFC 3111. Unfortunately, SLP hasn't been very widely used, though = there are a few very specific cases where it has been (iSCSI discovery, = SIP proxy discovery, among others). I would not be in favor of extending the RA for this purpose in any = case. LW DHCP is a better choice and has better possibility for wider = deployment, though somewhat more constrained than SLP in how services = are defined. jak ----- Original Message -----=20 From: Abhijit Chaudhary (abchaudh)=20 To: ipv6@ietf.org=20 Sent: Wednesday, August 03, 2005 10:22 PM Subject: IPv6 Service Discovery Hi, I have question regarding IPv6 auto service discovery.=20 Suppose a IPv6 Mobile Host comes and joins a network. Using Stateful = or Stateless Address Configuration mentioned in ICMPv6 Router = Advertisement message it gets a IPv6 address.=20 But if the mobile host want to know the nearest printer IP address or = the proxy address or DNS server address (i.e, IP address of Responder = mentioned in draft-ietf-ipngwg-icmp-name-lookups-12.txt). Is there any draft or RFC that talks about a procedure to get = information about Server providing application Service for IPv6? If not, I am of the impression that we can add a new option to Router = Advertisement message called "Application Service Discovery Proxy". This = option will contain the IPv6 address and Link-Layer address of the = "Application Service Discovery Proxy". This proxy will contain all the = information of the available application service in the network and the = corresponding servers. The new option will look as below: = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved = | =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address of Application Service Discovery Proxy = | + = | | +++++++++++++++++++++++++++++++++++++++++++++++ | = =20 ~ Link-Layer Address of Service Discovery Proxy = | =20 | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Exchange is described below: 1) Router Advertisement will contain the Application Service Discovery = Proxy Option "Router Advertisement with = Application Service Discovery Proxy Option" Router = -------------------------------------------------------------------------= --------------------------------------------------------> Host 2) Host gets the Address of the Application Service Discovery Proxy = and stores it. Suppose, the host wants printing service, it uses some = protocol (maybe UDP or XML over HTTP or ICMPv6) to discover services = from the Application Service Discovery Proxy. For Printing service the message as below: "Give me printer service = address"=20 1. Host = -------------------------------------------------------------------------= ---------------> Application Service Discovery Proxy=20 = "Printer IPv6 address =3D x, Printer LL address =3D y" 2. Application Service Discovery Proxy = -------------------------------------------------------------------------= --------------------------> Host "Sends data to be printed"=20 3. Host = -----------------------------------------------------------------------> = Printer Let me know what you guys feel about it. Thanks, - Abhijit -------------------------------------------------------------------------= ----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_NextPart_000_0ED5_01C59885.EA1CDE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Check RFC 3111. Unfortunately, SLP hasn't been very = widely=20 used, though there are a few very specific cases where it has been = (iSCSI=20 discovery, SIP proxy discovery, among others).
 
I would not be in favor of extending the RA for this = purpose=20 in any case. LW DHCP is a better choice and has better possibility for = wider=20 deployment, though somewhat more constrained than SLP in how services = are=20 defined.
 
        =    =20 jak
 
----- Original Message -----
From:=20 Abhijit Chaudhary=20 (abchaudh)
Sent: Wednesday, August 03, = 2005 10:22=20 PM
Subject: IPv6 Service = Discovery

Hi,
I = have question=20 regarding IPv6 auto service discovery. 
 
Suppose a IPv6=20 Mobile Host comes and joins a network. Using Stateful or Stateless = Address=20 Configuration mentioned in ICMPv6 Router  Advertisement message = it gets a=20 IPv6 address.
But if=20 the mobile host want to know the nearest printer IP address or = the proxy=20 address or DNS server address (i.e, IP address of Responder=20  mentioned in=20 draft-ietf-ipngwg-icmp-name-lookups-12.txt).
Is there any draft or RFC that talks about = a=20 procedure to get information about Server providing application = Service=20 for IPv6?
 
If not, I am of the impression that we can = add a new=20 option to Router  Advertisement message called "Application = Service=20 Discovery Proxy". This option will contain the IPv6 address and = Link-Layer=20 address of the "Application Service Discovery Proxy". This proxy=20 will contain all the information of the available application = service in=20 the network and the corresponding servers. The new option will = look as=20 below:
 
      +-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  &n= bsp;  =20 |     = Type        =20 |   =20 = Length           &= nbsp;=20 |           =20 = Reserved           = ;          =20 | 
     =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 |           IPv6 = Address of=20 Application  Service Discovery = Proxy      =20   |
     =20 = +            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =          =20 |
     =20 |  +++++++++++++++++++++++++++++++++++++++++++++++=20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;
     =20 ~         Link-Layer Address=20 of  Service Discovery=20 = Proxy           &n= bsp;      |   
 &nbs= p;   =20 = |            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =            =20 |
     =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /SPAN>
 
The Message Exchange is described=20 below:
 
1) Router Advertisement will contain the = Application=20 Service Discovery Proxy Option
       &nbs= p;            = ;            =  =20 "Router Advertisement with Application Service Discovery Proxy=20 Option"
       &nbs= p;        =20 Router =20 = -------------------------------------------------------------------------= -------------------------------------------------------->=20 Host
 
2) Host gets the Address of the Application = Service=20 Discovery Proxy and stores it. Suppose, the host = wants printing=20 service, it uses some protocol (maybe UDP or XML over HTTP or ICMPv6) = to=20 discover services from the Application Service Discovery=20 Proxy.
    For Printing service the = message=20 as below:
       &nbs= p;            = ;            =        =20 "Give me printer service address"
       &nbs= p;   1.    =20 Host=20 = -------------------------------------------------------------------------= --------------->  Application=20 Service Discovery Proxy
 
       &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;         =20 "Printer IPv6 address =3D x, Printer LL address =3D = y"
       &nbs= p;   2.    =20 Application Service Discovery Proxy=20 = -------------------------------------------------------------------------= -------------------------->=20 Host
 
       &nbs= p;            = ;            =            "Sends = data to be printed"
       &nbs= p;   3.     Host=20 = -----------------------------------------------------------------------&g= t;=20 Printer
 
Let me know what you guys feel about=20 it.
 
Thanks,
- Abhijit

=

------------------------------------------------------------------= --
IETF=20 IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests:=20 = https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------= ------------------------------------------
= ------=_NextPart_000_0ED5_01C59885.EA1CDE80-- --===============1971757042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1971757042==-- From ipv6-bounces@ietf.org Thu Aug 04 02:52:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZaX-0006ea-7s; Thu, 04 Aug 2005 02:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZaU-0006di-O2 for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 02:52:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04995 for ; Thu, 4 Aug 2005 02:52:17 -0400 (EDT) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0a7J-0008Ux-NS for ipv6@ietf.org; Thu, 04 Aug 2005 03:26:15 -0400 Received: from [86.255.27.220] by consulintel.es (MDaemon.PRO.v7.2.3.R) with ESMTP id md50001183832.msg for ; Thu, 04 Aug 2005 08:53:38 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Aug 2005 08:51:31 +0200 From: JORDI PALET MARTINEZ To: "ipv6@ietf.org" Message-ID: In-Reply-To: <20050804151339.5fb252f0.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 86.255.27.220 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.consulintel.es X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=ham version=2.64 X-Spam-Processed: consulintel.es, Thu, 04 Aug 2005 08:54:05 +0200 X-MDAV-Processed: consulintel.es, Thu, 04 Aug 2005 08:54:07 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Subject: Re: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, In my opinion SLP has some issues to be deployed, at least it has for our case when we worked in Tunnel End Point discovery (see section 3.5). http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-03.txt A more complete version is available at http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-pre- 03.txt Also, a possible solution: http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-solution-tun-auto- disc-01.txt I think that we worked out for TEP discovery could also be applicable for the discovery of other services. Regards, Jordi > De: Mark Smith > Responder a: > Fecha: Thu, 4 Aug 2005 15:13:39 +0930 > Para: "Abhijit Chaudhary (abchaudh)" > CC: "ipv6@ietf.org" > Asunto: Re: IPv6 Service Discovery > > Hi Abhijit, > > I don't know all that much about how it operates however, I think that > is what "SLP - Service Location Protocol" is designed for. From RFC2608 > - > > " The Service Location Protocol provides a scalable framework for the > discovery and selection of network services. Using this protocol, > computers using the Internet need little or no static configuration > of network services for network based applications. This is > especially important as computers become more portable, and users > less tolerant or able to fulfill the demands of network system > administration." > > I don't know enough about it to say whether it allows for or needs to be > updated to support IPv6. > > On a related note, I'd be curious to know if anybody is updating NetBIOS > over IP / CIFS to support IPv6. I'd think that NetBIOS / CIFS file and > print sharing probably carries more data on a daily basis than any other > IPv4 carried protocol. Maybe that is one cause for people not > introducing IPv6 to their enterprise networks - their most commonly used > application protocol isn't supported over it. > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ************************************ The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 02:53:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZbT-00077w-22; Thu, 04 Aug 2005 02:53:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZbQ-000766-Nx for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 02:53:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05097 for ; Thu, 4 Aug 2005 02:53:15 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0a8F-00006A-PI for ipv6@ietf.org; Thu, 04 Aug 2005 03:27:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j746kxUm006323; Thu, 4 Aug 2005 09:46:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 09:52:24 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Aug 2005 09:52:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2005 09:52:24 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEADA@esebe100.NOE.Nokia.com> Thread-Topic: IPv6 Service Discovery Thread-Index: AcWYtI7jzKPFZElIS0uy/+aieOKo9QADFpuw To: , X-OriginalArrivalTime: 04 Aug 2005 06:52:24.0707 (UTC) FILETIME=[11F16530:01C598C1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Abhijit, =20 What sort of Application Service are you talking about? I know folks = look at using DHCP for configuring this kind of information, if I = understand you correctly. =20 John -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of = ext Abhijit Chaudhary (abchaudh) Sent: 04 August, 2005 08:23 To: ipv6@ietf.org Subject: IPv6 Service Discovery Hi, I have question regarding IPv6 auto service discovery.=20 =20 Suppose a IPv6 Mobile Host comes and joins a network. Using Stateful or = Stateless Address Configuration mentioned in ICMPv6 Router = Advertisement message it gets a IPv6 address.=20 But if the mobile host want to know the nearest printer IP address or = the proxy address or DNS server address (i.e, IP address of Responder = mentioned in draft-ietf-ipngwg-icmp-name-lookups-12.txt). Is there any draft or RFC that talks about a procedure to get = information about Server providing application Service for IPv6? =20 If not, I am of the impression that we can add a new option to Router = Advertisement message called "Application Service Discovery Proxy". This = option will contain the IPv6 address and Link-Layer address of the = "Application Service Discovery Proxy". This proxy will contain all the = information of the available application service in the network and the = corresponding servers. The new option will look as below: =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved = | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address of Application Service Discovery Proxy = | + = | | +++++++++++++++++++++++++++++++++++++++++++++++ | = =20 ~ Link-Layer Address of Service Discovery Proxy = | =20 | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 The Message Exchange is described below: =20 1) Router Advertisement will contain the Application Service Discovery = Proxy Option "Router Advertisement with Application = Service Discovery Proxy Option" Router = -------------------------------------------------------------------------= --------------------------------------------------------> Host =20 2) Host gets the Address of the Application Service Discovery Proxy and = stores it. Suppose, the host wants printing service, it uses some = protocol (maybe UDP or XML over HTTP or ICMPv6) to discover services = from the Application Service Discovery Proxy. For Printing service the message as below: "Give me printer service = address"=20 1. Host = -------------------------------------------------------------------------= ---------------> Application Service Discovery Proxy=20 =20 = "Printer IPv6 address =3D x, Printer LL address =3D y" 2. Application Service Discovery Proxy = -------------------------------------------------------------------------= --------------------------> Host =20 "Sends data to be printed"=20 3. Host = -----------------------------------------------------------------------> = Printer =20 Let me know what you guys feel about it. =20 Thanks, - Abhijit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 03:23:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a4g-0001ur-Bj; Thu, 04 Aug 2005 03:23:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a4d-0001ug-Sw for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 03:23:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07156 for ; Thu, 4 Aug 2005 03:23:26 -0400 (EDT) Received: from loadbalancer2.orcon.net.nz ([219.88.242.4] helo=dbmail-mx4.orcon.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0abR-0001V5-3K for ipv6@ietf.org; Thu, 04 Aug 2005 03:57:24 -0400 Received: from elmer.coders.tla (60-234-141-149.bitstream.orcon.net.nz [60.234.141.149]) by dbmail-mx4.orcon.co.nz (8.13.2/8.13.2/Debian-1) with ESMTP id j747RAoL004553; Thu, 4 Aug 2005 19:27:10 +1200 Received: from breeze.dah.crc.net.nz ([10.1.20.9]) by elmer.coders.tla with esmtp (Exim 3.35 #1 (Debian)) id 1E0a3K-0001Vj-00; Thu, 04 Aug 2005 19:22:06 +1200 Message-ID: <42F1C21B.9030203@coders.net> Date: Thu, 04 Aug 2005 19:22:03 +1200 From: Perry Lorier User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050730 X-Accept-Language: en-nz, en MIME-Version: 1.0 To: "Abhijit Chaudhary (abchaudh)" References: <9E2962464AC4BD4E9CC38436D1F7789C2D98BF@xmb-blr-416.apac.cisco.com> In-Reply-To: <9E2962464AC4BD4E9CC38436D1F7789C2D98BF@xmb-blr-416.apac.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/1002/Wed Aug 3 22:29:36 2005 on dbmail-mx4.orcon.co.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Abhijit Chaudhary (abchaudh) wrote: > Hi, > I have question regarding IPv6 auto service discovery. > > Suppose a IPv6 Mobile Host comes and joins a network. Using Stateful or > Stateless Address Configuration mentioned in ICMPv6 Router > Advertisement message it gets a IPv6 address. > But if the mobile host want to know the nearest printer IP address or > the proxy address or DNS server address (i.e, IP address of Responder > mentioned in draft-ietf-ipngwg-icmp-name-lookups-12.txt). > Is there any draft or RFC that talks about a procedure to get > information about Server providing application Service for IPv6? I would have thought it would use DNS Service Discovery/Multicast DNS. http://www.multicastdns.org/ http://www.dns-sd.org/ While these protocols are mostly used under IPv4, I forsee[1] no reason why they shouldn't work in a mixed v6/v6 only network without change. They are well deployed already by being built into MacOS X, and some other platforms. [1]: I've not carefully studied these protocols however, so I suggest you consult others before declaring that these are ready for v6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 03:27:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a8n-0003nW-7x; Thu, 04 Aug 2005 03:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0a8l-0003nG-8x for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 03:27:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07424 for ; Thu, 4 Aug 2005 03:27:41 -0400 (EDT) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0afb-0001k6-FJ for ipv6@ietf.org; Thu, 04 Aug 2005 04:01:40 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 04 Aug 2005 13:01:02 -0700 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j747P4bs005344; Thu, 4 Aug 2005 07:27:21 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Aug 2005 12:48:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2005 12:48:57 +0530 Message-ID: <9E2962464AC4BD4E9CC38436D1F7789C2D9900@xmb-blr-416.apac.cisco.com> Thread-Topic: IPv6 Service Discovery Thread-Index: AcWYtI7jzKPFZElIS0uy/+aieOKo9QADFpuwAABP+MA= From: "Abhijit Chaudhary \(abchaudh\)" To: X-OriginalArrivalTime: 04 Aug 2005 07:18:58.0238 (UTC) FILETIME=[C7C2EDE0:01C598C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi John, I think DHCP server is used to find TFTP server, time server, Gateway, and maybe DNS too. I don't think it can be used to find Printers or other video application or VoIP server etc.=20 Maybe a DHCP expert can comment more on it. Generally DHCP server exist in the Service provider network, thus the customer DHCP Request may have to go through a DHCP Relay agent to reach the DHCP Server. Though DHCP server can also exist in the customer network too. Morever, in Stateless address configuration a DHCP server may not exist too. IMHO, I feel that address discovery and service discovery are separate and best done by separate server for each. - Abhijit=20 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Thursday, August 04, 2005 12:22 PM To: Abhijit Chaudhary (abchaudh); ipv6@ietf.org Subject: RE: IPv6 Service Discovery Abhijit, =20 What sort of Application Service are you talking about? I know folks look at using DHCP for configuring this kind of information, if I understand you correctly. =20 John -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of ext Abhijit Chaudhary (abchaudh) Sent: 04 August, 2005 08:23 To: ipv6@ietf.org Subject: IPv6 Service Discovery Hi, I have question regarding IPv6 auto service discovery.=20 =20 Suppose a IPv6 Mobile Host comes and joins a network. Using Stateful or Stateless Address Configuration mentioned in ICMPv6 Router Advertisement message it gets a IPv6 address.=20 But if the mobile host want to know the nearest printer IP address or the proxy address or DNS server address (i.e, IP address of Responder mentioned in draft-ietf-ipngwg-icmp-name-lookups-12.txt). Is there any draft or RFC that talks about a procedure to get information about Server providing application Service for IPv6? =20 If not, I am of the impression that we can add a new option to Router Advertisement message called "Application Service Discovery Proxy". This option will contain the IPv6 address and Link-Layer address of the "Application Service Discovery Proxy". This proxy will contain all the information of the available application service in the network and the corresponding servers. The new option will look as below: =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address of Application Service Discovery Proxy | + | | +++++++++++++++++++++++++++++++++++++++++++++++ | ~ Link-Layer Address of Service Discovery Proxy | =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 The Message Exchange is described below: =20 1) Router Advertisement will contain the Application Service Discovery Proxy Option "Router Advertisement with Application Service Discovery Proxy Option" Router ------------------------------------------------------------------------ ---------------------------------------------------------> Host =20 2) Host gets the Address of the Application Service Discovery Proxy and stores it. Suppose, the host wants printing service, it uses some protocol (maybe UDP or XML over HTTP or ICMPv6) to discover services from the Application Service Discovery Proxy. For Printing service the message as below: "Give me printer service address"=20 1. Host ------------------------------------------------------------------------ ----------------> Application Service Discovery Proxy=20 =20 =20 "Printer IPv6 address =3D x, Printer LL address =3D y" 2. Application Service Discovery Proxy ------------------------------------------------------------------------ ---------------------------> Host =20 "Sends data to be printed"=20 3. Host -----------------------------------------------------------------------> Printer =20 Let me know what you guys feel about it. =20 Thanks, - Abhijit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 03:43:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aNj-00014l-Tq; Thu, 04 Aug 2005 03:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aNg-00012G-31 for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 03:43:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08655 for ; Thu, 4 Aug 2005 03:43:06 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0auW-0002hC-EE for ipv6@ietf.org; Thu, 04 Aug 2005 04:17:05 -0400 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id B085A568BA; Thu, 4 Aug 2005 00:42:44 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <200508031229.IAA10942@ietf.org> References: <200508031229.IAA10942@ietf.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Conrad Date: Thu, 4 Aug 2005 00:42:41 -0700 To: Tony Hain X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: ARIN PPML , ipv6@ietf.org Subject: Re: potpourri X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Tony, I know I'm going to regret this since your post was so obviously flamebait preaching to the choir, but as the saying goes, you bring the flamethrower and I'll bring the marshmallows. On Aug 3, 2005, at 5:28 AM, Tony Hain wrote: > The IETF has to take the position of broad vision here > and flatly state that undue conservation is detrimental. Of course it is. And water is wet. The obvious point of contention is the definition of "undue". Your definition differs from others due to the fact that there are different interpretations of possible future utilization trends. The IETF's choice of a (relatively) small fixed number of bits guaranteed that this would be a problem, but hey, we sure showed those silly OSI fanatics and their obviously broken variable length addresses, didn't we? > The RIR members are basically a greedy bunch. No, no. The correct, IETF sanctioned term is "Evil Greedy Bastard". Just checked the T-shirt I got back in '94 at the ALE meeting and that's definitely what it says. Of course, I'm just one of the foxes in the henhouse now so I guess I need a different T-shirt. > Even so there are continuing complaints about the /64 boundary and > demands > to relax that constraint because in historical deployment terms > that number > of bits per subnet is a waste. Well, yes. There are those who feel 18,446,744,073,709,551,616 addresses is a bit much for any flat routed individual LAN, but those arguments are so passe these days. Auto-configuration is indeed nice, at least in those environments that don't mind having arbitrary devices connect to the network and get valid IP addresses, but I guess I just have a wee bit of concern with arbitrary fixed boundaries since they worked so stunningly well in the past. Must be a EGB flashback. I'm sure I'll get over it. > Never mind the issue that at some point in > the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit > EUI's... I suppose IPv6 will need to be revised so that the RFID addresses will fit. Oh, wait... > Fundamentally the RIR members just don't like being told what to do. I guess this is accurate. Perhaps, just maybe, the presumption that the IETF is qualified and/or appropriate to tell the RIR members what to do is where the dislike of being told what to do originates? > If left alone they will constrain network deployments to what has been > done in the past. No. If left alone, I would imagine they will constrain network deployments to what they believe will meet their business requirements. At least the commercial ones. If a particular RIR member believes what has been done in the past meets those requirements, that is probably what they will do. If they believe deploying IPv6 will meet their requirements, guess what will happen? > It is up to the IPv6 WG to set the bar to avoid the state > where people are forced to work around the restrictive policies of a > provider and/or LIR/RIR. I would have thought it was the IPv6 WG's responsibility to standardize protocols that would address the issues that resulted in the restrictive policies. The issue of address space limitations was sort-of addressed (in a sub-optimal way given this discussion). But how about issues like transparent renumbering, multi-homing, separation of the end point identifier from the routing locator, and/ or other issues around routing system scalability? For example, people are going to be forced to work around the restrictive policy that you have to renumber when you change providers. I personally suspect they'll do that via NATv6. If you're true to form, I'm sure you'll argue they'll do that by some variant of geographical addressing. Since the EGBs you have such disdain for would have to play nicely together to go with your scheme and they don't have to do anything to support NATv6, I have a sneaking suspicion which approach will be deployed for the folks whose definition of the Internet is the World Wide Web and whose interpretation of "end-to-end" is something you find on those unmentionable web sites that, of course, they'd never go to (wink, wink, nudge, nudge). Looking at the existing RIR databases, the "restrictive policies" (most of which were taken verbatim from the IETF holy texts) you deride have already resulted in /19s being allocated to single organizations (which, coincidentally, used to be the same prefix length RIPE-NCC used to allocate to LIRs when they initially requested space. IPv4 /19s, of course). And this is without governments requesting the space they feel they'll need for their national interests. Governments like, oh say, China, India, Indonesia, etc. If a /20 can be justified and allocated to Telstra or Telia, how much address space should (say) the People's Liberation Army of China get? > Those who point to the phone > system as an example conveniently overlook the rolling evolution that > effectively reduces the window of applicability. While there may be > pockets > where things still work, in my experience equipment from 40 years > ago is not > compatible with the current network My dad has a Stromberg-Carlson model 1212-A made in the 1930s. I just spoke with him over it. Seems to be compatible. Not full featured by today's standards, but it does appear to do the function it was built for. But perhaps you mean something else. > Even the numbering has undergone periodic > change, so claiming we know enough to recognize allocation waste > centuries > before the person with a bright new idea is born is the highest > form of > arrogance. Alternatively, claiming we know enough to assume profligate waste will not cause the exact same arguments sometime within the foreseeable future could simply reiterate Hegel's quote "Those who cannot learn from history are doomed to repeat it". I would however agree with you on one thing: there is a lot of arrogance here. Rgds, -drc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 03:56:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aaF-00062N-W3; Thu, 04 Aug 2005 03:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0aaD-00060z-Cx for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 03:56:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09334 for ; Thu, 4 Aug 2005 03:56:03 -0400 (EDT) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0b71-0003Dm-QP for ipv6@ietf.org; Thu, 04 Aug 2005 04:30:02 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id BB4A45538; Thu, 4 Aug 2005 09:55:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id B925454FE; Thu, 4 Aug 2005 09:55:33 +0200 (CEST) Date: Thu, 4 Aug 2005 09:55:33 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Abhijit Chaudhary (abchaudh)" In-Reply-To: <9E2962464AC4BD4E9CC38436D1F7789C2D9900@xmb-blr-416.apac.cisco.com> Message-ID: <20050804094455.E82753@mignon.ki.iif.hu> References: <9E2962464AC4BD4E9CC38436D1F7789C2D9900@xmb-blr-416.apac.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: john.loughney@nokia.com, ipv6@ietf.org Subject: RE: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 4 Aug 2005, Abhijit Chaudhary (abchaudh) wrote: > Hi John, > I think DHCP server is used to find TFTP server, time server, Gateway, > and maybe DNS too. > I don't think it can be used to find Printers or other video application > or VoIP server etc. I don't see any problem to configure these services via DHCP. Alternatively you could use SLP. > Maybe a DHCP expert can comment more on it. > Generally DHCP server exist in the Service provider network, thus the > customer DHCP Request may have to go through a DHCP Relay agent to reach > the DHCP Server. Though DHCP server can also exist in the customer > network too. > Morever, in Stateless address configuration a DHCP server may not exist > too. Perfectly usable scenario is to use RA and SLAAC for configure addresses, gateway, link MTU etc. and stateless DHCP for DNS, NTP, potentially SIP servers... > > IMHO, I feel that address discovery and service discovery are separate > and best done by separate server for each. Agree. Can you describe your scenario, where RA is more suitable for service discovery? Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > - Abhijit > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, August 04, 2005 12:22 PM > To: Abhijit Chaudhary (abchaudh); ipv6@ietf.org > Subject: RE: IPv6 Service Discovery > > Abhijit, > > What sort of Application Service are you talking about? I know folks > look at using DHCP for configuring this kind of information, if I > understand you correctly. > > John > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of > ext Abhijit Chaudhary (abchaudh) > Sent: 04 August, 2005 08:23 > To: ipv6@ietf.org > Subject: IPv6 Service Discovery > > > Hi, > I have question regarding IPv6 auto service discovery. > > Suppose a IPv6 Mobile Host comes and joins a network. Using Stateful or > Stateless Address Configuration mentioned in ICMPv6 Router > Advertisement message it gets a IPv6 address. > But if the mobile host want to know the nearest printer IP address or > the proxy address or DNS server address (i.e, IP address of Responder > mentioned in draft-ietf-ipngwg-icmp-name-lookups-12.txt). > Is there any draft or RFC that talks about a procedure to get > information about Server providing application Service for IPv6? > > If not, I am of the impression that we can add a new option to Router > Advertisement message called "Application Service Discovery Proxy". This > option will contain the IPv6 address and Link-Layer address of the > "Application Service Discovery Proxy". This proxy will contain all the > information of the available application service in the network and the > corresponding servers. The new option will look as below: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv6 Address of Application Service Discovery Proxy > | > + > | > | +++++++++++++++++++++++++++++++++++++++++++++++ | > > ~ Link-Layer Address of Service Discovery Proxy > | > | > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The Message Exchange is described below: > > 1) Router Advertisement will contain the Application Service Discovery > Proxy Option > "Router Advertisement with Application > Service Discovery Proxy Option" > Router > ------------------------------------------------------------------------ > ---------------------------------------------------------> Host > > 2) Host gets the Address of the Application Service Discovery Proxy and > stores it. Suppose, the host wants printing service, it uses some > protocol (maybe UDP or XML over HTTP or ICMPv6) to discover services > from the Application Service Discovery Proxy. > For Printing service the message as below: > "Give me printer service > address" > 1. Host > ------------------------------------------------------------------------ > ----------------> Application Service Discovery Proxy > > > "Printer IPv6 address = x, Printer LL address = y" > 2. Application Service Discovery Proxy > ------------------------------------------------------------------------ > ---------------------------> Host > > "Sends data to be printed" > 3. Host > -----------------------------------------------------------------------> > Printer > > Let me know what you guys feel about it. > > Thanks, > - Abhijit > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 04:20:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0atL-000595-0a; Thu, 04 Aug 2005 04:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0atA-00056C-1e; Thu, 04 Aug 2005 04:15:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10696; Thu, 4 Aug 2005 04:15:38 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0bQ1-0004EP-3Z; Thu, 04 Aug 2005 04:49:37 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E0at9-00028t-89; Thu, 04 Aug 2005 04:15:39 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 04 Aug 2005 04:15:39 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'A Method for Generating Link Scoped IPv6 Multicast Addresses' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'A Method for Generating Link Scoped IPv6 Multicast Addresses ' as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-09.txt Technical Summary This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate their unique multicast addresses automatically without conflicts. Basically, this document proposes an alternative method for creating link-local multicast addresses over a known method like unicast-prefix-based IPv6 multicast addresses. It is preferred to use this method for link-local scope rather than unicast- prefix-based IPv6 multicast addresses. This memo update RFC3306. Working Group Summary This document was produced by the IPv6 WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 04:58:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bYg-0005JP-Dw; Thu, 04 Aug 2005 04:58:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bYe-0005IO-FB for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 04:58:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13693 for ; Thu, 4 Aug 2005 04:58:30 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0c5U-0006R1-G4 for ipv6@ietf.org; Thu, 04 Aug 2005 05:32:30 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j748wAD05228; Thu, 4 Aug 2005 10:58:10 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j748wAkZ018997; Thu, 4 Aug 2005 10:58:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508040858.j748wAkZ018997@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Srinivas Goud In-reply-to: Your message of Thu, 04 Aug 2005 10:39:00 +0530. Date: Thu, 04 Aug 2005 10:58:10 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipv6@ietf.org, =?ISO-2022-JP?Q?JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= Subject: Re: IPv6 Final Destination Option X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: I do agree with your points, but if you loot at rfc3775, ... => the question is a bit different: is it silly to define a mutable option which can only be in the final destination option header so cannot be mute en route? This is true but you can't infer that options at this place must be not mutable. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 07:56:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eKb-0002wu-9M; Thu, 04 Aug 2005 07:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eKZ-0002wp-Iy for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 07:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29354 for ; Thu, 4 Aug 2005 07:56:10 -0400 (EDT) Received: from srv0001.pine.nl ([213.156.9.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0erR-0006gJ-4E for ipv6@ietf.org; Thu, 04 Aug 2005 08:30:10 -0400 Received: from localhost (localhost [127.0.0.1]) by srv0001.pine.nl (Pine Digital Security Mailer [srv0001.pine.nl]) with ESMTP id 2438D3972BD; Thu, 4 Aug 2005 13:55:50 +0200 (CEST) Received: from srv0001.pine.nl ([127.0.0.1]) by localhost (srv0001.pine.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 90294-01-3; Thu, 4 Aug 2005 13:55:21 +0200 (CEST) Received: from [86.255.25.113] (open-25-113.ietf63.ietf.org [86.255.25.113]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by srv0001.pine.nl (Pine Digital Security Mailer [srv0001.pine.nl]) with ESMTP id 239BC397238; Thu, 4 Aug 2005 13:55:21 +0200 (CEST) In-Reply-To: <42F1C21B.9030203@coders.net> References: <9E2962464AC4BD4E9CC38436D1F7789C2D98BF@xmb-blr-416.apac.cisco.com> <42F1C21B.9030203@coders.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D50C20B-FB75-4004-89B3-5BD68EBE185D@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 4 Aug 2005 13:55:19 +0200 To: Perry Lorier X-Mailer: Apple Mail (2.733) X-Virus-Scanned: by amavisd-new at pine.nl X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: IPv6 Service Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 4-aug-2005, at 9:22, Perry Lorier wrote: > I would have thought it would use DNS Service Discovery/Multicast DNS. > http://www.multicastdns.org/ > http://www.dns-sd.org/ > While these protocols are mostly used under IPv4, I forsee[1] no > reason > why they shouldn't work in a mixed v6/v6 only network without change. > They are well deployed already by being built into MacOS X, and some > other platforms. Apple implements this as Bonjour (formerly Rendezvous), and see http://www.zeroconf.org/ I've seen Bonjour/Rendezvous work over IPv6 without trouble, but sometimes the availability of different ways to do the same thing (v4 +v6, wireless/ether) complicates things a bit. The use of multicast DNS, or possibly dynamic DNS, is more appropriate for discovering services than DHCP or RA, because it allows hosts offering services to advertise those services autonomously rather than requiring an admin to add them to the DHCP server or router. (Or having to implement complex new mechanisms to make this happen automatically.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 04 13:33:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jbO-00074e-Hp; Thu, 04 Aug 2005 13:33:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jbM-00072S-Ah for ipv6@megatron.ietf.org; Thu, 04 Aug 2005 13:33:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26058 for ; Thu, 4 Aug 2005 13:33:49 -0400 (EDT) Message-Id: <200508041733.NAA26058@ietf.org> Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0k8H-0002Gi-9B for ipv6@ietf.org; Thu, 04 Aug 2005 14:07:54 -0400 Received: from eaglet (127.0.0.1:4690) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 4 Aug 2005 10:33:26 -0700 From: "Tony Hain" To: "'David Conrad'" Date: Thu, 4 Aug 2005 19:33:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWYyBYBPm3ZxOIVQ5K2ifcazpUh0AARbKng X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit Cc: 'ARIN PPML' , ipv6@ietf.org Subject: RE: potpourri X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org David Conrad wrote: > Tony, > > I know I'm going to regret this since your post was so obviously > flamebait preaching to the choir, but as the saying goes, you bring > the flamethrower and I'll bring the marshmallows. > > On Aug 3, 2005, at 5:28 AM, Tony Hain wrote: > > The IETF has to take the position of broad vision here > > and flatly state that undue conservation is detrimental. > > Of course it is. And water is wet. > > The obvious point of contention is the definition of "undue". Your > definition differs from others due to the fact that there are > different interpretations of possible future utilization trends. The > IETF's choice of a (relatively) small fixed number of bits guaranteed > that this would be a problem, but hey, we sure showed those silly OSI > fanatics and their obviously broken variable length addresses, didn't > we? To recall history, I was a proponent of TUBA (TCP over NSAPs), simply due to getting things done quickly... That is irrelevant though as we now have what we have. Yes we differ on the definition of 'undue'. My definition says that we should have more than enough to last us until the replacement is deployed. Three will be all kinds of reasons for that to happen before 2100, not the least of which is that yet to be born researchers will be continuously looking for the 'optimal' approaches to move bits around. History shows that the definition of 'optimal' varies based on perspective and the specific application at hand. Yes we should make sure that if no better ideas come along before the end of the century that we can sustain until that happens, but we don't need to make it last longer than recorded history. > > > The RIR members are basically a greedy bunch. > > No, no. The correct, IETF sanctioned term is "Evil Greedy Bastard". > Just checked the T-shirt I got back in '94 at the ALE meeting and > that's definitely what it says. Of course, I'm just one of the foxes > in the henhouse now so I guess I need a different T-shirt. I was not trying to create hostilities, just point out that complaining about the other guy having too many when you already have more than 'more than enough' can only be described as greed. > > > Even so there are continuing complaints about the /64 boundary and > > demands > > to relax that constraint because in historical deployment terms > > that number > > of bits per subnet is a waste. > > Well, yes. There are those who feel 18,446,744,073,709,551,616 > addresses is a bit much for any flat routed individual LAN, but those > arguments are so passe these days. Auto-configuration is indeed > nice, at least in those environments that don't mind having arbitrary > devices connect to the network and get valid IP addresses, but I > guess I just have a wee bit of concern with arbitrary fixed > boundaries since they worked so stunningly well in the past. Must be > a EGB flashback. I'm sure I'll get over it. > > > Never mind the issue that at some point in > > the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit > > EUI's... > > I suppose IPv6 will need to be revised so that the RFID addresses > will fit. Oh, wait... > > > Fundamentally the RIR members just don't like being told what to do. > > I guess this is accurate. Perhaps, just maybe, the presumption that > the IETF is qualified and/or appropriate to tell the RIR members what > to do is where the dislike of being told what to do originates? The IETF can and should say what the technical issues and trade-off's are. The policies about managing within those constraints is not the IETF's business. > > > If left alone they will constrain network deployments to what has been > > done in the past. > > No. If left alone, I would imagine they will constrain network > deployments to what they believe will meet their business > requirements. 'Their business requirements' is the key here. Those without voice are left to take what they can get, and will innovate with bypass technologies (like skype) when they can't get what they really want. > At least the commercial ones. If a particular RIR > member believes what has been done in the past meets those > requirements, that is probably what they will do. If they believe > deploying IPv6 will meet their requirements, guess what will happen? History shows that their requirements end up being restrictions on what their customers can do. Until there is true competition which allows people to shop for service that meets their needs there will be bypass technologies developed to get around the arbitrary restrictions. We don't need bypass technologies for artificially restricted address allocations. > > > It is up to the IPv6 WG to set the bar to avoid the state > > where people are forced to work around the restrictive policies of a > > provider and/or LIR/RIR. > > I would have thought it was the IPv6 WG's responsibility to > standardize protocols that would address the issues that resulted in > the restrictive policies. The issue of address space limitations was > sort-of addressed (in a sub-optimal way given this discussion). But > how about issues like transparent renumbering, multi-homing, > separation of the end point identifier from the routing locator, and/ > or other issues around routing system scalability? Those are interesting topics but they were/are not design requirements for the packet transport protocol between networks. What the IPv6 WG has done is define the pieces to replace those associated with IPv4 as packet transport between networks. > > For example, people are going to be forced to work around the > restrictive policy that you have to renumber when you change > providers. I personally suspect they'll do that via NATv6. If > you're true to form, I'm sure you'll argue they'll do that by some > variant of geographical addressing. I don't care what form PI takes. My proposal is just one way that happens to work with the existing BGP and has a managed degree of aggregation. I tried to get a bof at this IETF to talk about the general issue of aggregating approaches to PI but it was turned down because people are putting too much faith in shim6. > Since the EGBs you have such > disdain for would have to play nicely together to go with your scheme > and they don't have to do anything to support NATv6, I have a > sneaking suspicion which approach will be deployed for the folks > whose definition of the Internet is the World Wide Web and whose > interpretation of "end-to-end" is something you find on those > unmentionable web sites that, of course, they'd never go to (wink, > wink, nudge, nudge). See draft-ietf-v6ops-nap-01.txt > > Looking at the existing RIR databases, the "restrictive > policies" (most of which were taken verbatim from the IETF holy > texts) you deride have already resulted in /19s being allocated to > single organizations (which, coincidentally, used to be the same > prefix length RIPE-NCC used to allocate to LIRs when they initially > requested space. IPv4 /19s, of course). And this is without > governments requesting the space they feel they'll need for their > national interests. Governments like, oh say, China, India, > Indonesia, etc. If a /20 can be justified and allocated to Telstra > or Telia, how much address space should (say) the People's Liberation > Army of China get? Misinterpretation of host measures as useful in allocating network prefixes is not an IETF issue. Using the proposed measure of .94 would fix the basic problem you raise. Not fixing that will result in the ITU helping answer your last question. > > > Those who point to the phone > > system as an example conveniently overlook the rolling evolution that > > effectively reduces the window of applicability. While there may be > > pockets > > where things still work, in my experience equipment from 40 years > > ago is not > > compatible with the current network > > My dad has a Stromberg-Carlson model 1212-A made in the 1930s. I > just spoke with him over it. Seems to be compatible. Not full > featured by today's standards, but it does appear to do the function > it was built for. But perhaps you mean something else. My rotary dial model is able to receive but not place calls. Placing calls is a fundamental requirement in my experience. YMMV ;) > > > Even the numbering has undergone periodic > > change, so claiming we know enough to recognize allocation waste > > centuries > > before the person with a bright new idea is born is the highest > > form of > > arrogance. > > Alternatively, claiming we know enough to assume profligate waste > will not cause the exact same arguments sometime within the > foreseeable future could simply reiterate Hegel's quote "Those who > cannot learn from history are doomed to repeat it". Our difference is in the measure of 'waste'. Your claim is that there is waste in allocating the same number of bits to the subnet as to routing. The number of bits used by a subnet is completely irrelevant because that was decided after the number of bits used for routing was decided to be more than enough to meet the design goals. The discussion about /48 vs. /56 is simply about the amount of cushion in routing bits that will be 'wasted' after IPv6 is replaced. If we knew the date that cool new innovations would drive a replacement for IPv6 we could optimize allocations to exactly meet the need. The best we can do is target a lifetime, and several centuries that are the result of /48's with an HD of .94 is likely to be more than long enough. Tony > > I would however agree with you on one thing: there is a lot of > arrogance here. > > Rgds, > -drc -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Aug 07 00:01:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1cLM-0001gz-8J; Sun, 07 Aug 2005 00:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1cLK-0001ep-DG for ipv6@megatron.ietf.org; Sun, 07 Aug 2005 00:00:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28895 for ; Sun, 7 Aug 2005 00:00:55 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1csj-0008CQ-Qv for ipv6@ietf.org; Sun, 07 Aug 2005 00:35:31 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 9385F634 for ; Sun, 7 Aug 2005 00:00:37 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 07 Aug 2005 00:00:37 -0400 Message-Id: <20050807040037.9385F634@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 9.68% | 9 | 6.65% | 34789 | francis.dupont@enst-bretagne.fr 5.38% | 5 | 7.15% | 37413 | jinmei@isl.rdc.toshiba.co.jp 6.45% | 6 | 5.47% | 28604 | iljitsch@muada.com 5.38% | 5 | 4.47% | 23385 | tjc@ecs.soton.ac.uk 4.30% | 4 | 5.37% | 28069 | alh-ietf@tndh.net 3.23% | 3 | 4.83% | 25252 | brian@innovationslab.net 4.30% | 4 | 3.73% | 19535 | ipng@69706e6720323030352d30312d31340a.nosense.org 4.30% | 4 | 3.63% | 18974 | perry@coders.net 4.30% | 4 | 3.09% | 16157 | ericlklein@softhome.net 3.23% | 3 | 3.93% | 20540 | mohacsi@niif.hu 2.15% | 2 | 4.88% | 25529 | abchaudh@cisco.com 3.23% | 3 | 3.24% | 16928 | stig.venaas@uninett.no 3.23% | 3 | 2.92% | 15284 | john.loughney@nokia.com 3.23% | 3 | 2.74% | 14350 | pekkas@netcore.fi 2.15% | 2 | 3.12% | 16339 | ronald.pashby.ctr@navy.mil 1.08% | 1 | 4.03% | 21078 | kempf@docomolabs-usa.com 2.15% | 2 | 2.63% | 13747 | cnugoud@gmail.com 2.15% | 2 | 1.89% | 9874 | smadanapalli@gmail.com 2.15% | 2 | 1.57% | 8189 | greg.daley@eng.monash.edu.au 2.15% | 2 | 1.44% | 7557 | erik.nordmark@sun.com 2.15% | 2 | 1.39% | 7280 | suresh.krishnan@ericsson.com 1.08% | 1 | 1.85% | 9673 | jim.bound@hp.com 1.08% | 1 | 1.70% | 8888 | david.conrad@nominum.com 1.08% | 1 | 1.24% | 6489 | a@arifumi.net 1.08% | 1 | 1.22% | 6364 | elwynd@dial.pipex.com 1.08% | 1 | 1.17% | 6098 | volz@cisco.com 1.08% | 1 | 1.10% | 5762 | jordi.palet@consulintel.es 1.08% | 1 | 1.07% | 5579 | fred@cisco.com 1.08% | 1 | 1.01% | 5276 | fred.l.templin@boeing.com 1.08% | 1 | 0.97% | 5054 | sra+ipng@hactrn.net 1.08% | 1 | 0.91% | 4742 | gvandeve@cisco.com 1.08% | 1 | 0.89% | 4658 | nwnetworks@dial.pipex.com 1.08% | 1 | 0.87% | 4560 | shawn.smith1.ctr@disa.mil 1.08% | 1 | 0.85% | 4448 | brc@zurich.ibm.com 1.08% | 1 | 0.84% | 4373 | fujisaki@syce.net 1.08% | 1 | 0.83% | 4353 | ted.lemon@nominum.com 1.08% | 1 | 0.83% | 4323 | yoshfuji@linux-ipv6.org 1.08% | 1 | 0.80% | 4173 | huitema@windows.microsoft.com 1.08% | 1 | 0.78% | 4095 | iesg-secretary@ietf.org 1.08% | 1 | 0.78% | 4092 | soohong.park@samsung.com 1.08% | 1 | 0.78% | 4090 | bob.hinden@nokia.com 1.08% | 1 | 0.69% | 3615 | mailman-owner@ietf.org 1.08% | 1 | 0.69% | 3608 | harford@bluewavelabs.com --------+------+--------+----------+------------------------ 100.00% | 93 |100.00% | 523186 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 08 15:44:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DYD-0002Hi-OE; Mon, 08 Aug 2005 15:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DYB-0002Hd-LX for ipv6@megatron.ietf.org; Mon, 08 Aug 2005 15:44:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13384 for ; Mon, 8 Aug 2005 15:44:41 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2E5v-000204-Oy for ipv6@ietf.org; Mon, 08 Aug 2005 16:19:37 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j78JiRTb003574 for ; Mon, 8 Aug 2005 21:44:27 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j78JiR26022263 for ; Mon, 8 Aug 2005 21:44:27 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j78JiREd022262 for ipv6@ietf.org; Mon, 8 Aug 2005 21:44:27 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 8 Aug 2005 21:44:27 +0200 From: Stig Venaas To: ipv6@ietf.org Message-ID: <20050808194427.GB21924@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org RFC 3484, and implementations thereof, allows for a sysadmin to configure address selection policy on a single host. I think this is useful, and I suppose also the wg since the RFC was published. One typical example might be preferring IPv4 over IPv6. If I as a site administrator want all the hosts at my site to prefer IPv4 over IPv6, I need to distribute that policy to all of them. I hope you can understand the need for that. In that case, I think we should try to look for possible solutions. Some applications might want to specify their own particular behaviour, but I see several reasons why an administrator may want to specify a default. Using DHCP may be one solution. The only alternative available today, is to log into every single host and run each host's OS specific commands to change the policy. This might work for hosts that are centrally administrated at that site. It would not work for hosts visiting that network or under different management. Do you agree this is something that should be solved? It's probably a good idea to discuss that before going into particular solutions. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 08 16:16:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2E3J-0001h3-7B; Mon, 08 Aug 2005 16:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2E3H-0001fK-3R for ipv6@megatron.ietf.org; Mon, 08 Aug 2005 16:16:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21380 for ; Mon, 8 Aug 2005 16:16:48 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Eaz-0005Ay-5x for ipv6@ietf.org; Mon, 08 Aug 2005 16:51:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 08 Aug 2005 13:16:36 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j78KGYoo005686; Mon, 8 Aug 2005 13:16:34 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j78KDbVm017180; Mon, 8 Aug 2005 13:13:37 -0700 In-Reply-To: <20050808194427.GB21924@storhaugen.uninett.no> References: <20050808194427.GB21924@storhaugen.uninett.no> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Mon, 8 Aug 2005 13:16:32 -0700 To: Stig Venaas X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=1460; t=1123532017; x=1123964217; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Distribution=20of=20RFC=203484=20address=20selection=20policies| From:Fred=20Baker=20| Date:Mon,=208=20Aug=202005=2013=3A16=3A32=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=Jv+pEDq4837HNn7K6xNawLQgib0aKBobBjUcJXivgVlA3h+wH6gM3eXWvO9b0lLDyK/WhpGm rwEKARTJcK3p00OYwDBLhRnboJ246nqxzMLtYEyBwMrVrnzkmfAufZ8BcjV7aNZlAl14IiAZE8L EGweEE2cL/LxXdJD328f1nqU= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org personally, I an see a *lot* of reasons to leave such decisions in the hand of the administration. The most compelling is: "try taking it out of the administration's hands. Just try. I dare ya." DHCP/DHCPv6 seems like a reasonable choice of dynamic host configuration protocol. On Aug 8, 2005, at 12:44 PM, Stig Venaas wrote: > RFC 3484, and implementations thereof, allows for a sysadmin to > configure address selection policy on a single host. I think this is > useful, and I suppose also the wg since the RFC was published. One > typical example might be preferring IPv4 over IPv6. > > If I as a site administrator want all the hosts at my site to prefer > IPv4 over IPv6, I need to distribute that policy to all of them. I > hope you can understand the need for that. In that case, I think we > should try to look for possible solutions. Some applications might > want to specify their own particular behaviour, but I see several > reasons why an administrator may want to specify a default. > > Using DHCP may be one solution. The only alternative available today, > is to log into every single host and run each host's OS specific > commands to change the policy. This might work for hosts that are > centrally administrated at that site. It would not work for hosts > visiting that network or under different management. > > Do you agree this is something that should be solved? It's probably > a good idea to discuss that before going into particular solutions. > > Stig > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 08 16:40:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2EQR-0008M8-RI; Mon, 08 Aug 2005 16:40:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2EQN-0008Lx-Lw for ipv6@megatron.ietf.org; Mon, 08 Aug 2005 16:40:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23507 for ; Mon, 8 Aug 2005 16:40:41 -0400 (EDT) Received: from paddock.ermy.net ([62.189.30.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2Ey8-00067c-H3 for ipv6@ietf.org; Mon, 08 Aug 2005 17:15:37 -0400 Received: (qmail 2055 invoked from network); 8 Aug 2005 20:40:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 8 Aug 2005 20:40:04 -0000 Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Mark K. Thompson" Date: Mon, 8 Aug 2005 21:40:06 +0100 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On 8 Aug 2005, at 21:16, Fred Baker wrote: > personally, I an see a *lot* of reasons to leave such decisions in > the hand of the administration. The most compelling is: "try taking > it out of the administration's hands. Just try. I dare ya." > > DHCP/DHCPv6 seems like a reasonable choice of dynamic host > configuration protocol. Naturally I concur, however two technical challenges leap out at me concerning the nature of the policy table as specified by RFC3484. First, the lack of field definition for labels has seen different OSes use different datatypes for the label, from string through stringified-integer to integer. Any cross-platform policy specification protocol would need to cater for this inconsistency. Perhaps this is something that a RFC3484-bis could address when making that spec compliant with the requirements of RFC3879 Section 4? Also, RFC3484 permits the specification of zone index in the policy (c.f section 2.1). Section 6 of RFC4007 explicitly states that zone indices are strictly local to the node, making any centralisation of RFC3484 policy "challenging". [aside: OK, so administrators could harvest index data for links on which scoped-policy is required and then maintained in the DHCPv6 server as specific for that node, but there's no protocol for that harvesting and I've not surveyed sufficient implementations to determine whether indexes persist and are consistent between reboots] So, yes, I agree that centralisation of address selection of policy is important (and necessary for folks using ULAs with greater-than- site scope multicast), and that DHCPv6 appears a reasonable choice, but there are fundamental issues with RFC3484 that need to be addressed at the outset. Mark/ -- Dr Mark K. Thompson Electronics and Computer Science a School of the University of Southampton, UK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 08 19:58:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2HVv-0000OV-3U; Mon, 08 Aug 2005 19:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2HVu-0000OP-2O for ipv6@megatron.ietf.org; Mon, 08 Aug 2005 19:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02685 for ; Mon, 8 Aug 2005 19:58:34 -0400 (EDT) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2I3g-0002KV-AO for ipv6@ietf.org; Mon, 08 Aug 2005 20:33:34 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRMCBLDRQE9AQ2JT@vaxh.its.monash.edu.au> for ipv6@ietf.org; Tue, 09 Aug 2005 09:58:07 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4F4B8AB545; Tue, 09 Aug 2005 09:58:07 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2E0824FB02; Tue, 09 Aug 2005 09:58:07 +1000 (EST) Date: Tue, 09 Aug 2005 09:58:06 +1000 From: Greg Daley In-reply-to: To: "Mark K. Thompson" Message-id: <42F7F18E.2000102@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: IETF IPv6 Mailing List Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Mark, Mark K. Thompson wrote: [cut] > > So, yes, I agree that centralisation of address selection of policy is > important (and necessary for folks using ULAs with greater-than- site > scope multicast), and that DHCPv6 appears a reasonable choice, but > there are fundamental issues with RFC3484 that need to be addressed at > the outset. I mentioned in the DHC session that prefix and routing configuration decisions in IPv6 typically aren't controlled through DHC. They are controlled through router discovery (RFC2461). More specific routes and router selection are also performed by modifications to ND Router Advertisement messages. I therefore don't think it is a good fit to proceed with DHC options for the purpose of source address selection default policy. So I think I agree with you, that determination whether centralized control is valid needs to occur, before delving into solutions (solution looking for problems was heard in that session). Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 08 20:34:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2I4d-0000Bu-4H; Mon, 08 Aug 2005 20:34:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2I4b-0000Bm-07 for ipv6@megatron.ietf.org; Mon, 08 Aug 2005 20:34:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07826 for ; Mon, 8 Aug 2005 20:34:27 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2IcN-0004U9-VF for ipv6@ietf.org; Mon, 08 Aug 2005 21:09:25 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Aug 2005 17:34:19 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j790YGZ1002174; Mon, 8 Aug 2005 17:34:16 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j790VIKs019346; Mon, 8 Aug 2005 17:31:18 -0700 In-Reply-To: <42F7F18E.2000102@eng.monash.edu.au> References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Mon, 8 Aug 2005 17:34:13 -0700 To: greg.daley@eng.monash.edu.au X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=1195; t=1123547478; x=1123979678; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Distribution=20of=20RFC=203484=20address=20selection=20policies| From:Fred=20Baker=20| Date:Mon,=208=20Aug=202005=2017=3A34=3A13=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=gtZXI7R8WaMofVEmABbSXUw9rXqiLsF4ICWHxpjrwtJCgbzP6sIhjZqxAuOl5rIdsYjuqA8W rWcE0qogndjj1eqb3IH0/hiGzs3Cwq1m3LXCb4Qbn3OygpFzwe1KGnAvP+AhyQy1scz5CYUm+Fo aGxc0dIC9U73dMkiHWOVnQ4Y= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org how do the routers (which control router discovery) get this policy information? On Aug 8, 2005, at 4:58 PM, Greg Daley wrote: > Hi Mark, > > Mark K. Thompson wrote: > [cut] > >> So, yes, I agree that centralisation of address selection of >> policy is important (and necessary for folks using ULAs with >> greater-than- site scope multicast), and that DHCPv6 appears a >> reasonable choice, but there are fundamental issues with RFC3484 >> that need to be addressed at the outset. >> > > I mentioned in the DHC session that prefix and routing configuration > decisions in IPv6 typically aren't controlled through DHC. > > They are controlled through router discovery (RFC2461). More specific > routes and router selection are also performed by modifications to > ND Router Advertisement messages. > > I therefore don't think it is a good fit to proceed with DHC options > for the purpose of source address selection default policy. > > So I think I agree with you, that determination whether > centralized control is valid needs to occur, before delving into > solutions (solution looking for problems was heard in that session). > > Greg > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 08 22:26:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2JpM-0007DK-9e; Mon, 08 Aug 2005 22:26:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2JpK-0007DB-Ft for ipv6@megatron.ietf.org; Mon, 08 Aug 2005 22:26:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23664 for ; Mon, 8 Aug 2005 22:26:48 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2KN7-0007IB-W2 for ipv6@ietf.org; Mon, 08 Aug 2005 23:01:47 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRMHFKWQQ48Y9FNX@vaxc.its.monash.edu.au> for ipv6@ietf.org; Tue, 09 Aug 2005 12:24:54 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7597DAB543; Tue, 09 Aug 2005 12:24:53 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4F7A14FB0C; Tue, 09 Aug 2005 12:24:53 +1000 (EST) Date: Tue, 09 Aug 2005 12:24:51 +1000 From: Greg Daley In-reply-to: To: Fred Baker Message-id: <42F813F3.7050005@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7BIT Cc: IETF IPv6 Mailing List Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Fred, Fred Baker wrote: > how do the routers (which control router discovery) get this policy > information? There's no existing mechanism for describing the source address selection policies using router discovery. For router discovery itself though, the configured IPv6 prefixes are typically configured through configuration files. I'd guess there are proprietary MIBs to describe this as well. I'm not sure anyone is doing it, but renumbering is applicable there as a means of providing information about which prefixes are valid. I'd guess that any mechanism which interacted with router discovery to provide address selection policy would need to be integrated with the ND messages, and the configuration systems applicable to those messages. Greg. > On Aug 8, 2005, at 4:58 PM, Greg Daley wrote: > >> Hi Mark, >> >> Mark K. Thompson wrote: >> [cut] >> >>> So, yes, I agree that centralisation of address selection of policy >>> is important (and necessary for folks using ULAs with greater-than- >>> site scope multicast), and that DHCPv6 appears a reasonable choice, >>> but there are fundamental issues with RFC3484 that need to be >>> addressed at the outset. >>> >> >> I mentioned in the DHC session that prefix and routing configuration >> decisions in IPv6 typically aren't controlled through DHC. >> >> They are controlled through router discovery (RFC2461). More specific >> routes and router selection are also performed by modifications to >> ND Router Advertisement messages. >> >> I therefore don't think it is a good fit to proceed with DHC options >> for the purpose of source address selection default policy. >> >> So I think I agree with you, that determination whether >> centralized control is valid needs to occur, before delving into >> solutions (solution looking for problems was heard in that session). >> >> Greg >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 08 23:13:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2KYW-0006vI-9F; Mon, 08 Aug 2005 23:13:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2KYT-0006vA-Qv for ipv6@megatron.ietf.org; Mon, 08 Aug 2005 23:13:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25199 for ; Mon, 8 Aug 2005 23:13:27 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2L6H-0008GN-UR for ipv6@ietf.org; Mon, 08 Aug 2005 23:48:27 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7936shK021410; Tue, 9 Aug 2005 06:06:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 06:13:21 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Aug 2005 06:13:21 +0300 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2005 06:13:19 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CEB1D@esebe100.NOE.Nokia.com> Thread-Topic: Distribution of RFC 3484 address selection policies Thread-Index: AcWcVucOMHwjZf8JSx6Kh0dRDbJqIgAOPfxQ To: , X-OriginalArrivalTime: 09 Aug 2005 03:13:21.0271 (UTC) FILETIME=[4BE8F870:01C59C90] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Stig, > Do you agree this is something that should be solved? It's probably > a good idea to discuss that before going into particular solutions. I think this is a good thing to work on. I'd like to point out that there are several related pieces of work interested in similar = functionality. The monami bof is interested in multihoming and address selection for MIPv6 - I was unable to attend that bof, so I don't know how that turned out. Also, address selection in a multihomed environment will be very useful for shim6. I'm thinking that if there are some other groups looking at similar=20 functions, that should point to a need to work on solutions. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 09 04:57:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Pvg-0003kd-U1; Tue, 09 Aug 2005 04:57:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Pve-0003kW-Op for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 04:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23125 for ; Tue, 9 Aug 2005 04:57:41 -0400 (EDT) Received: from p127202.doubleroute.jp ([219.119.127.202] helo=s51.ath.cx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2QTT-0000G2-Bh for ipv6@ietf.org; Tue, 09 Aug 2005 05:32:44 -0400 Received: from [192.47.163.103] (dhcp-3-103.nttv6.com [192.47.163.103]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by s51.ath.cx (Postfix) with ESMTP id 6DA7570C2F; Tue, 9 Aug 2005 17:57:04 +0900 (JST) In-Reply-To: <200508030733.j737XlET014823@givry.rennes.enst-bretagne.fr> References: <200508030733.j737XlET014823@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII Message-Id: <075F5A2F-F212-4C14-A2FF-3E351A10E2D5@arifumi.net> Content-Transfer-Encoding: 7bit From: Arifumi Matsumoto Date: Tue, 9 Aug 2005 17:57:15 +0900 To: ipv6@ietf.org X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.6 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: Tim Chown , Francis Dupont Subject: Re: Policy for use of privacy addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Sorry for my late comment. This is what I told Tim after dhc session, though. On 2005/08/03, at 16:33, Francis Dupont wrote: > In your previous mail you wrote: > > In a managed DHC environment, privacy addresses can be returned by DHCPv6 > for client use, but my reading of RFC3315 suggests (section 12) that the > request is client initiated, which implies there should/could be some policy > that could be distributed by DHCP itself to hint to the client that it can > make the request. > > I appreciate Keith's point that per-application (non) usage may also be > desirable, but there is an API being proposed for that? It should probably > have some relationship to the site policy though? > > => this point is supposed to be solved by RFC 3484 and related APIs but: > - the private/public address switch (rule 7) is not in the policy table > - related APIs assume that every applications were changed in order to > use them (so they are nearly useless). > > Regards Of course, the privacy/public address switch isn't in the policy table, you can control it by configuring policy table in not a beautiful way. It's too simple. Just put a privacy address with 128-bit prefix-len into the policy table. Prefix Prec Label 2001:db8:1:1:a:b:c:d/128 1 1 <-- privacy address 2001:db8:1:1::/64 10 2 ::/0 10 2 In this case, the privacy address won't be used anymore to any dst by default address selection. Alternatively, you can specify public address with 128-bit prefix-len and can prioritize public address over privacy one, or vice versa. Prefix Prec Label 2001:db8:1:1:a:b:c:d/128 10 2 <-- public address 2001:db8:1:1::/64 1 1 ::/0 10 2 In this case, the privacy address will be used to connect to the hosts on the same link, though. As a privacy address is re-generated periodically, the policy table has to be updated accordingly in the former case. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories TEL: +81-422-59-3334 / FAX: +81-422-59-5652 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 09 06:29:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RMB-0003Yq-Pv; Tue, 09 Aug 2005 06:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RM6-0003YR-CI for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 06:29:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26678 for ; Tue, 9 Aug 2005 06:29:07 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Rtv-0002XD-W9 for ipv6@ietf.org; Tue, 09 Aug 2005 07:04:11 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j79ASnTb000611; Tue, 9 Aug 2005 12:28:49 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j79ASnKQ026365; Tue, 9 Aug 2005 12:28:49 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j79ASg8N026364; Tue, 9 Aug 2005 12:28:42 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 9 Aug 2005 12:28:42 +0200 From: Stig Venaas To: Arifumi Matsumoto Message-ID: <20050809102841.GA26200@storhaugen.uninett.no> References: <200508030733.j737XlET014823@givry.rennes.enst-bretagne.fr> <075F5A2F-F212-4C14-A2FF-3E351A10E2D5@arifumi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <075F5A2F-F212-4C14-A2FF-3E351A10E2D5@arifumi.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Francis Dupont , Tim Chown , ipv6@ietf.org Subject: Re: Policy for use of privacy addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Aug 09, 2005 at 05:57:15PM +0900, Arifumi Matsumoto wrote: > Sorry for my late comment. > This is what I told Tim after dhc session, though. > > On 2005/08/03, at 16:33, Francis Dupont wrote: > > > In your previous mail you wrote: > > > > In a managed DHC environment, privacy addresses can be returned by DHCPv6 > > for client use, but my reading of RFC3315 suggests (section 12) that the > > request is client initiated, which implies there should/could be some policy > > that could be distributed by DHCP itself to hint to the client that it can > > make the request. > > > > I appreciate Keith's point that per-application (non) usage may also be > > desirable, but there is an API being proposed for that? It should probably > > have some relationship to the site policy though? > > > > => this point is supposed to be solved by RFC 3484 and related APIs but: > > - the private/public address switch (rule 7) is not in the policy table > > - related APIs assume that every applications were changed in order to > > use them (so they are nearly useless). > > > > Regards > > Of course, the privacy/public address switch isn't in the policy table, > you can control it by configuring policy table in not a beautiful way. > > It's too simple. Just put a privacy address with 128-bit prefix-len > into the policy table. > > Prefix Prec Label > 2001:db8:1:1:a:b:c:d/128 1 1 <-- privacy address > 2001:db8:1:1::/64 10 2 > ::/0 10 2 > > In this case, the privacy address won't be used anymore to any dst by > default address selection. > > Alternatively, you can specify public address with 128-bit prefix-len > and can prioritize public address over privacy one, or vice versa. > > Prefix Prec Label > 2001:db8:1:1:a:b:c:d/128 10 2 <-- public address > 2001:db8:1:1::/64 1 1 > ::/0 10 2 > > In this case, the privacy address will be used to connect to the hosts > on the same link, though. > > As a privacy address is re-generated periodically, the policy table has > to be updated accordingly in the former case. This seems a bit ugly though (should be a way to refer to privacy address so that you don't need to update the policy table yourself whenever you get a new privacy address), and I think whether to use privacy source address is mainly an application decision. There is a proposed socket API for this which I think is more useful. My main concern with applications and privacy addresses are applications that get all addresses on an interface and then pass one or more of those at the application layer to someone else (e.g. referrals). How does it know which to pass. When an application gets a list of all addresses on an interface, how does it determine which are privacy addresses and which are not. I also believe it would be useful to have a way the kernel can tell an app that the addresses on an interface has changed. This would be useful for privacy addresses and also for renumbering. E.g. something like the netlink socket stuff which some systems use to tell applications of routing changes. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 09 06:53:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Rjc-0004CD-S2; Tue, 09 Aug 2005 06:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Rja-0004C5-6J for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 06:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27821 for ; Tue, 9 Aug 2005 06:53:22 -0400 (EDT) Received: from p127202.doubleroute.jp ([219.119.127.202] helo=s51.ath.cx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2SHS-000368-QV for ipv6@ietf.org; Tue, 09 Aug 2005 07:28:27 -0400 Received: from [192.47.163.103] (dhcp-3-103.nttv6.com [192.47.163.103]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by s51.ath.cx (Postfix) with ESMTP id 4442B70C2F; Tue, 9 Aug 2005 19:53:12 +0900 (JST) In-Reply-To: References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII Message-Id: Content-Transfer-Encoding: 7bit From: Arifumi Matsumoto Date: Tue, 9 Aug 2005 19:53:22 +0900 To: "Mark K. Thompson" X-Mailer: Apple Mail (2.733) X-Spam-Score: 2.6 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Mark, On 2005/08/09, at 5:40, Mark K. Thompson wrote: > > On 8 Aug 2005, at 21:16, Fred Baker wrote: > > >> personally, I an see a *lot* of reasons to leave such decisions in the hand of the administration. The most compelling is: "try taking it out of the administration's hands. Just try. I dare ya." >> >> DHCP/DHCPv6 seems like a reasonable choice of dynamic host configuration protocol. >> > > Naturally I concur, however two technical challenges leap out at me concerning the nature of the policy table as specified by RFC3484. > > First, the lack of field definition for labels has seen different OSes use different datatypes for the label, from string through stringified-integer to integer. Any cross-platform policy specification protocol would need to cater for this inconsistency. Perhaps this is something that a RFC3484-bis could address when making that spec compliant with the requirements of RFC3879 Section 4? let me comment one thing. By our protocol, we intend to distribute an address selection policy, of course, but the values in this option aren't absolute but relative. When an option includes the following, for example: Prefix Precedence Label 2001:db8::/48 100 10 3ffe:db8::/48 20 10 2002:1:2::/48 10 5 The Label values just indicate that the first line and the second line has the same label and the third line doesn't have the same label as any other lines. This is the case with Precedence value. This option indicates the order of precedence. So, if a host has its policy table configured manually and has the label value 10, the distributed policy's label value should be changed to another un-used value or string. About Precedence, the values in distributed option can be changed as far as the order isn't changed. So, this just seems to me an issue of implementation on DHCPv6 option receiver. It may be better to clarify these implementation considerations in our draft or in another draft. > > Also, RFC3484 permits the specification of zone index in the policy (c.f section 2.1). Section 6 of RFC4007 explicitly states that zone indices are strictly local to the node, making any centralisation of RFC3484 policy "challenging". [aside: OK, so administrators could harvest index data for links on which scoped-policy is required and then maintained in the DHCPv6 server as specific for that node, but there's no protocol for that harvesting and I've not surveyed sufficient implementations to determine whether indexes persist and are consistent between reboots] Actually, we aren't sure that this field is necessary. We also have never heard a case harvesting it. As you mention it, this value is local in a node, so there may be no use to distribute it in a centralized manner. -- Arifumi Matsumoto -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 09 07:26:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2SFq-0007pP-3g; Tue, 09 Aug 2005 07:26:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2SFm-0007ot-5T for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 07:26:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29250 for ; Tue, 9 Aug 2005 07:26:40 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Snf-00042y-NC for ipv6@ietf.org; Tue, 09 Aug 2005 08:01:44 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j79BPkn24357; Tue, 9 Aug 2005 13:25:46 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j79BPj5t041390; Tue, 9 Aug 2005 13:25:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508091125.j79BPj5t041390@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Arifumi Matsumoto In-reply-to: Your message of Tue, 09 Aug 2005 17:57:15 +0900. <075F5A2F-F212-4C14-A2FF-3E351A10E2D5@arifumi.net> Date: Tue, 09 Aug 2005 13:25:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Tim Chown , ipv6@ietf.org Subject: Re: Policy for use of privacy addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: > => this point is supposed to be solved by RFC 3484 and related APIs but: > - the private/public address switch (rule 7) is not in the policy table > - related APIs assume that every applications were changed in order to > use them (so they are nearly useless). > > Regards Of course, the privacy/public address switch isn't in the policy table, you can control it by configuring policy table in not a beautiful way. => this is less than not a beautiful way... It's too simple. Just put a privacy address with 128-bit prefix-len into the policy table. => first there are good implementations which don't match 001 prefixes over 64 bits, second privacy addresses are highly temporary. As a privacy address is re-generated periodically, the policy table has to be updated accordingly in the former case. => the policy table is not supposed to be so dynamic. IMHO we need a proper solution for rules which can't be configured through the policy table... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 09 07:34:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2SNE-0003Pl-6H; Tue, 09 Aug 2005 07:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2SNC-0003Pg-G0 for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 07:34:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29676 for ; Tue, 9 Aug 2005 07:34:21 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Sv5-0004IF-Rk for ipv6@ietf.org; Tue, 09 Aug 2005 08:09:24 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j79BXxn24973; Tue, 9 Aug 2005 13:33:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j79BXxwg041472; Tue, 9 Aug 2005 13:33:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508091133.j79BXxwg041472@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stig Venaas In-reply-to: Your message of Tue, 09 Aug 2005 12:28:42 +0200. <20050809102841.GA26200@storhaugen.uninett.no> Date: Tue, 09 Aug 2005 13:33:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org, Tim Chown , Arifumi Matsumoto Subject: Re: Policy for use of privacy addresses? X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: > > => this point is supposed to be solved by RFC 3484 and related APIs but: > > - the private/public address switch (rule 7) is not in the policy table > > - related APIs assume that every applications were changed in order to > > use them (so they are nearly useless). There is a proposed socket API for this which I think is more useful. => this API assumes that every applications are changed in order to use it. IMHO something in the context of applications should be more useful (in the context == in environment variables, for instance). My main concern with applications and privacy addresses are applications that get all addresses on an interface and then pass one or more of those at the application layer to someone else (e.g. referrals). How does it know which to pass. When an application gets a list of all addresses on an interface, how does it determine which are privacy addresses and which are not. => I believe that low end mechanisms can give this information (i.e., it can be in given flags when addresses are dumped). I also believe it would be useful to have a way the kernel can tell an app that the addresses on an interface has changed. This would be useful for privacy addresses and also for renumbering. E.g. something like the netlink socket stuff which some systems use to tell applications of routing changes. => PF_ROUTE has this. BTW I believe it is better to have a more abstract view: managing addresses at this level is very (too?) painful... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 09 12:32:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X29-0005Kg-CW; Tue, 09 Aug 2005 12:32:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X27-0005Jp-5S for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 12:32:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21297 for ; Tue, 9 Aug 2005 12:32:52 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Xa2-0005mn-7I for ipv6@ietf.org; Tue, 09 Aug 2005 13:07:59 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Aug 2005 09:32:44 -0700 X-IronPort-AV: i="3.96,92,1122879600"; d="scan'208"; a="330495703:sNHT33241164" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j79GWcoo011184; Tue, 9 Aug 2005 09:32:41 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j79GTcUH023954; Tue, 9 Aug 2005 09:29:38 -0700 In-Reply-To: <42F813F3.7050005@eng.monash.edu.au> References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Tue, 9 Aug 2005 09:32:35 -0700 To: greg.daley@eng.monash.edu.au X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=1290; t=1123604979; x=1124037179; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Distribution=20of=20RFC=203484=20address=20selection=20policies| From:Fred=20Baker=20| Date:Tue,=209=20Aug=202005=2009=3A32=3A35=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=HazDFhhLdeSlC2uCjc0MfJrP+WeHwb4JF616ZcARAaijUu1AZQVHplNN06HwcQUZ0TINW4a3 w24h/5WPjcyac+//uHGGkOUdY/bfEYT3NiTId7MLwW04R4lg/55hE0wYrvWze/59MLmw0NEc8ju dMF1+I3mztYuhvqvTm7jIdoo= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Aug 8, 2005, at 7:24 PM, Greg Daley wrote: > I'm not sure anyone is doing it, but renumbering is applicable > there as a means of providing information about which prefixes are > valid. One of the outcomes of the v6ops WG last week was the observation that the Router Renumbering Protocol is not widely implemented, and when renumbering-in-anger persuant to http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering- procedure-05.txt "Procedures for Renumbering an IPv6 Network without a Flag Day", Fred Baker, 18-Mar-05, was tested by the 6net folks, it was found wanting in a variety of ways. Basically, it made the special case where you want to distribute a new aggregated prefix and maintain the same subnet number distribution (such as "I have changed upstream provider") pretty simple, but didn't cover any of the other cases in which one might want to renumber, and didn't handle any of the nuances like making sure this also happened in route maps, aggregation filters, qos classification filters, etc. As the discussion proceeded, we basically decided that renumbering (and more generally number distribution and number use policy) was the province of the network management folks, perhaps netconf. They need to decide how to manage a network, and if a protocol like RRP is part of that, specify a set of requirements for it. RRP at minimum needs work, and I would suggest it be declared "historic" and replaced with a new protocol if such a definition happens. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Aug 09 23:51:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hcn-0000yK-Q2; Tue, 09 Aug 2005 23:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hcm-0000yF-1a for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 23:51:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03185 for ; Tue, 9 Aug 2005 23:51:25 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2iAn-0008Gb-1j for ipv6@ietf.org; Wed, 10 Aug 2005 00:26:38 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRNYR3JW6C8X1JGL@vaxc.its.monash.edu.au> for ipv6@ietf.org; Wed, 10 Aug 2005 13:51:21 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8B6D18000D; Wed, 10 Aug 2005 13:51:20 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 690773C010; Wed, 10 Aug 2005 13:51:20 +1000 (EST) Date: Wed, 10 Aug 2005 13:51:19 +1000 From: Greg Daley In-reply-to: To: Fred Baker Message-id: <42F979B7.1020005@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7BIT Cc: IETF IPv6 Mailing List Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Fred. Fred Baker wrote: > On Aug 8, 2005, at 7:24 PM, Greg Daley wrote: > >> I'm not sure anyone is doing it, but renumbering is applicable there >> as a means of providing information about which prefixes are valid. > > > One of the outcomes of the v6ops WG last week was the observation that > the Router Renumbering Protocol is not widely implemented, and when > renumbering-in-anger persuant to > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering- > procedure-05.txt > "Procedures for Renumbering an IPv6 Network without a Flag Day", Fred > Baker, > 18-Mar-05, > > was tested by the 6net folks, it was found wanting in a variety of > ways. Basically, it made the special case where you want to distribute > a new aggregated prefix and maintain the same subnet number > distribution (such as "I have changed upstream provider") pretty > simple, but didn't cover any of the other cases in which one might want > to renumber, and didn't handle any of the nuances like making sure this > also happened in route maps, aggregation filters, qos classification > filters, etc. > > As the discussion proceeded, we basically decided that renumbering (and > more generally number distribution and number use policy) was the > province of the network management folks, perhaps netconf. They need to > decide how to manage a network, and if a protocol like RRP is part of > that, specify a set of requirements for it. RRP at minimum needs work, > and I would suggest it be declared "historic" and replaced with a new > protocol if such a definition happens. Sure. I guess that if automated generation of policy mappings for source address selection are required then it would be useful to work on this in concert with the main thrust of network management. Moving RRP to Historic may leave questions unanswered in peoples' heads regarding the ISP change scenario, but I really think moving the focus to SHIM6 (which provides host-to-host survivability of renumbering events) may actually be the better course (Shim6 people can take aim now). What's reasonable here with regard to address usage is to provide indications of the network's perception of differences between addresses to hosts. The actual task of managing the network's perception isn't really any different in DHCPv6 or Router Discovery (it's either automated or manual). The hosts receiving the default policy aren't ever aware of the mechanism used. As you mention, RRP may not be a valid way to do this configuration today (or in future), but config files, SNMP and misuses of RADIUS (not actually recommended) may be. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 00:01:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hm5-00046P-Ig; Wed, 10 Aug 2005 00:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hm3-00044b-2p for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 00:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03645 for ; Wed, 10 Aug 2005 00:01:00 -0400 (EDT) Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2iK3-0008WQ-BJ for ipv6@ietf.org; Wed, 10 Aug 2005 00:36:13 -0400 Received: from S018431 ([68.160.186.73]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IKZ00FTAN5MO7T6@vms048.mailsrvcs.net> for ipv6@ietf.org; Tue, 09 Aug 2005 23:00:59 -0500 (CDT) Date: Wed, 10 Aug 2005 00:00:55 -0400 From: "timothy enos" In-reply-to: <20050808194427.GB21924@storhaugen.uninett.no> To: "'Stig Venaas'" , Message-id: <001401c59d60$1d1cb8d0$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: Subject: RE: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Greetings all, I believe it is better to update RFC 3484, as well as decide how to best distribute address selection policies derived there from. Speaking of source address selection, note that in section 3.1: 'Use of the source address selection algorithm in the presence of multicast destination addresses requires the comparison of a unicast address scope with a multicast address scope... we map unicast site- local to multicast site-local... For example, unicast site-local is equal to multicast site-local... This mapping implicitly conflates unicast site boundaries and multicast site boundaries' Unicast site-local addresses were formally deprecated in RFC 3879. Presuming the concept of site for multicast to be well enough defined so as to not be deprecated, it doesn't seem logical to still conflate it with something that has been. At the very least, this is the case with new implementations (as in initial implementation being post-RFC 3879). Regarding destination address selection, please note in section 3.2: 'IPv4 private addresses... are assigned site-local scope.' These are unicast addresses, for which the ill-defined (concept of) site-local has been deprecated. In a post-RFC 3879 implementation, this also seems illogical. Continuing on to section 4, regarding candidate source addresses: 'For site-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface.' Given RFC 3879, there is no compelling case for what constitutes a site in the unicast address space. Therefore, we seemingly cannot meet the aforementioned MUST condition. (Yes, I know that site-local multicast addresses have not been deprecated.) Moving on to section 5 (source address selection), it is possible that a site-local unicast address could be chosen by Rule 2. In section 6 (destination address selection), Rule 2 is more definitive (a site-local unicast address could be chosen here as well). RFC 4007 seems to bolster the argument for updating of RFC 3484, given RFC 3879. See section 1: 'Though the current address architecture specification [1] defines unicast site-local addresses, the IPv6 working group decided to deprecate the syntax and the usage [5] and is now investigating other forms of local IPv6 addressing.' Since both the syntax and the usage of unicast site-local addresses has been deprecated, this is a case for updating RFC 3484 (RFC 3513 is about to be updated: see draft-ietf-ipv6-addr-arch-v4-04.txt). Please also note the beginning of section 10 (routing): 'Note that as unicast site-local addresses are deprecated, and link- local addresses do not need routing, the discussion in this section only applies to multicast scoped routing.' It is difficult to route to/through something that effectively no longer exists. There is also the matter of IPv4-compatible addresses being deprecated (draft-ietf-ipv6-addr-arch-v4-04.txt is in the RFC Editor queue; section 2.5.5.1 of this document delineates the deprecation). > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Stig Venaas > Sent: Monday, August 08, 2005 3:44 PM > To: ipv6@ietf.org > Subject: Distribution of RFC 3484 address selection policies > > RFC 3484, and implementations thereof, allows for a sysadmin to > configure address selection policy on a single host. I think this is > useful, and I suppose also the wg since the RFC was published. One > typical example might be preferring IPv4 over IPv6. > > If I as a site administrator want all the hosts at my site to prefer > IPv4 over IPv6, I need to distribute that policy to all of them. I > hope you can understand the need for that. Yes. > In that case, I think we > should try to look for possible solutions. Some applications might > want to specify their own particular behaviour, but I see several > reasons why an administrator may want to specify a default. > > Using DHCP may be one solution. The only alternative available today, > is to log into every single host and run each host's OS specific > commands to change the policy. This might work for hosts that are > centrally administrated at that site. It would not work for hosts > visiting that network or under different management. A possibility for the future (realizing it does not presently exist) seems to be the creation of a new Router Advertisement option. This could be something that would be received and used by clients of both DHCPv6 and SLAC. Using DHCP to distribute RFC 3484 address selection policies would seem to work for DHCP clients, yet not for SLAC clients. > > Do you agree this is something that should be solved? Yes. > It's probably > a good idea to discuss that before going into particular solutions. > > Stig > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- Best regards, Tim Enos 1Sam16:7 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 03:24:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2kx3-0007sk-Ob; Wed, 10 Aug 2005 03:24:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2kx1-0007sb-4U for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 03:24:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09232 for ; Wed, 10 Aug 2005 03:24:33 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2lV3-0004b0-Rd for ipv6@ietf.org; Wed, 10 Aug 2005 03:59:47 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRO678TLUE8Y9S7E@vaxc.its.monash.edu.au> for ipv6@ietf.org; Wed, 10 Aug 2005 17:24:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1DB69AB542; Wed, 10 Aug 2005 17:24:24 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id F2C084FB04; Wed, 10 Aug 2005 17:24:23 +1000 (EST) Date: Wed, 10 Aug 2005 17:24:23 +1000 From: Greg Daley In-reply-to: <001401c59d60$1d1cb8d0$bcf0fea9@S018431> To: timothy enos Message-id: <42F9ABA7.3030404@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <001401c59d60$1d1cb8d0$bcf0fea9@S018431> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org, 'Stig Venaas' Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Tim, timothy enos wrote: [cut] >>In that case, I think we >>should try to look for possible solutions. Some applications might >>want to specify their own particular behaviour, but I see several >>reasons why an administrator may want to specify a default. >> >>Using DHCP may be one solution. The only alternative available today, >>is to log into every single host and run each host's OS specific >>commands to change the policy. This might work for hosts that are >>centrally administrated at that site. It would not work for hosts >>visiting that network or under different management. > > > A possibility for the future (realizing it does not presently exist) > seems to be the creation of a new Router Advertisement option. This > could be something that would be received and used by clients of both > DHCPv6 and SLAC. > > Using DHCP to distribute RFC 3484 address selection policies would seem > to work for DHCP clients, yet not for SLAC clients. > I'd guess that it may not be necessary to define a new ND option to manage the preferences of prefixes, as there are 37 bits unallocated in the Prefix Information Option (32 bit Reserved2 field + remnant of Reserved1 field) [RFC3775 S7.2,RFC2461 S4.6.2]. I'd suggest that if preferences are all that's needed, then the function matches that for which the options are used now. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 03:42:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2lE7-0004KR-Tt; Wed, 10 Aug 2005 03:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2lE5-0004KM-MB for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 03:42:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09900 for ; Wed, 10 Aug 2005 03:42:12 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2lm8-0005A9-Sp for ipv6@ietf.org; Wed, 10 Aug 2005 04:17:26 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7A7g3Tb016173 for ; Wed, 10 Aug 2005 09:42:03 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7A7g3oD000752 for ; Wed, 10 Aug 2005 09:42:03 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7A7g3lW000751 for ipv6@ietf.org; Wed, 10 Aug 2005 09:42:03 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 10 Aug 2005 09:42:03 +0200 From: Stig Venaas To: ipv6@ietf.org Message-ID: <20050810074203.GB583@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org So far two principal solutions have been suggested, RAs and DHCP. If people want to work on solutions we could possibly look into both of these. Some issues have already been mentioned on this list. Another issue which was brought up in dhc wg, is that the policy is a host global config, not per interface. This might be an issue when you have multiple interfaces. This needs to be considered for both RAs and DHCP. I have two problems with RAs. One is that all hosts on the link will get the same policy. The other is that I'm worried the policies may get large, and I'm not sure if it's a good idea to send relatively large RAs regularly to all the nodes on a link. Size could also be a problem for DHCP if people want to create very complex policies. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 04:23:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2lsS-0006d1-HH; Wed, 10 Aug 2005 04:23:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2lsR-0006cr-C6 for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 04:23:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11944 for ; Wed, 10 Aug 2005 04:23:53 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2mQV-0006LB-NM for ipv6@ietf.org; Wed, 10 Aug 2005 04:59:08 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7A8NkTb025576; Wed, 10 Aug 2005 10:23:46 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7A8NkP9000919; Wed, 10 Aug 2005 10:23:46 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7A8NkVO000918; Wed, 10 Aug 2005 10:23:46 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 10 Aug 2005 10:23:46 +0200 From: Stig Venaas To: Greg Daley Message-ID: <20050810082345.GD583@storhaugen.uninett.no> References: <001401c59d60$1d1cb8d0$bcf0fea9@S018431> <42F9ABA7.3030404@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F9ABA7.3030404@eng.monash.edu.au> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipv6@ietf.org Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Aug 10, 2005 at 05:24:23PM +1000, Greg Daley wrote: [...] > I'd suggest that if preferences are all that's needed, then the > function matches that for which the options are used now. I agree that if only prefix preference is needed (possibly also v4 vs v6), then it seems obvious to learn this together with the prefixes themselves. I.e. if you use slaac, then also get the preference that way (similarly with dhcp or other mechanisms). The preference is for destination address selection, right? So a question then is whether that is enough or if there are many cases where the full policy (including source address selection) is needed. If the full policy is needed in some cases, then we have to consider whether it's worth having two solutions. I don't know myself, I think it requires further study. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 05:20:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2mkp-0003sw-Dr; Wed, 10 Aug 2005 05:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2mkl-0003s3-U2 for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 05:20:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14549 for ; Wed, 10 Aug 2005 05:20:01 -0400 (EDT) Received: from p127202.doubleroute.jp ([219.119.127.202] helo=s51.ath.cx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2nIk-0007tM-Ac for ipv6@ietf.org; Wed, 10 Aug 2005 05:55:17 -0400 Received: by s51.ath.cx (Postfix, from userid 1000) id 4AB6870C31; Wed, 10 Aug 2005 18:19:33 +0900 (JST) Date: Wed, 10 Aug 2005 18:19:33 +0900 From: a@arifumi.net To: Stig Venaas Message-ID: <20050810091933.GA15594@s51.ath.cx> References: <001401c59d60$1d1cb8d0$bcf0fea9@S018431> <42F9ABA7.3030404@eng.monash.edu.au> <20050810082345.GD583@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050810082345.GD583@storhaugen.uninett.no> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.9 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipv6@ietf.org Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Wed, Aug 10, 2005 at 10:23:46AM +0200, Stig Venaas wrote: > On Wed, Aug 10, 2005 at 05:24:23PM +1000, Greg Daley wrote: > [...] > > I'd suggest that if preferences are all that's needed, then the > > function matches that for which the options are used now. > > I agree that if only prefix preference is needed (possibly also > v4 vs v6), then it seems obvious to learn this together with the > prefixes themselves. I.e. if you use slaac, then also get the > preference that way (similarly with dhcp or other mechanisms). > The preference is for destination address selection, right? > > So a question then is whether that is enough or if there are > many cases where the full policy (including source address > selection) is needed. If the full policy is needed in some cases, > then we have to consider whether it's worth having two solutions. > > I don't know myself, I think it requires further study. I myself think that full policy is needed, of course. But, even if you define a option only for prefix *preference* for this framework of policy table, I wonder what the label value should be. As for IPv4 and IPv6 selection, even if you choose an arbitrary label value, it doesn't have any effects on source address selection. But, once that option is used for multiple IPv6 prefixes, the label value has some effects on source address selection also. So, as far as you use the policy table framework as it is, IMHO, you have to distribute prefix preference with label value. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 05:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2muU-0006iu-5f; Wed, 10 Aug 2005 05:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2muO-0006fp-DL for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 05:30:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15563 for ; Wed, 10 Aug 2005 05:29:58 -0400 (EDT) Received: from p127202.doubleroute.jp ([219.119.127.202] helo=s51.ath.cx) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2nSP-0008Jv-9i for ipv6@ietf.org; Wed, 10 Aug 2005 06:05:13 -0400 Received: by s51.ath.cx (Postfix, from userid 1000) id 396E770C33; Wed, 10 Aug 2005 18:29:51 +0900 (JST) Date: Wed, 10 Aug 2005 18:29:50 +0900 From: a@arifumi.net To: Stig Venaas Message-ID: <20050810092950.GB15594@s51.ath.cx> References: <20050810074203.GB583@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050810074203.GB583@storhaugen.uninett.no> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.9 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Stig, On Wed, Aug 10, 2005 at 09:42:03AM +0200, Stig Venaas wrote: > So far two principal solutions have been suggested, RAs and DHCP. If > people want to work on solutions we could possibly look into both of > these. > > Some issues have already been mentioned on this list. Another issue > which was brought up in dhc wg, is that the policy is a host global > config, not per interface. This might be an issue when you have > multiple interfaces. This needs to be considered for both RAs and > DHCP. > > I have two problems with RAs. One is that all hosts on the link will > get the same policy. The other is that I'm worried the policies may > get large, and I'm not sure if it's a good idea to send relatively > large RAs regularly to all the nodes on a link. > > Size could also be a problem for DHCP if people want to create very > complex policies. > > Stig Thank you for your clarification to the point. Actually, we proposed both RA and DHCP options for source address selection at first. But we came to think that DHCP is more appropriate for this purpose for the reasons you raised above. Also, DHCP-Lite is stateless as you know, so it seems to us that it is much easier to implement and to operate for almost all the cases we suppose. That is why we focus on DHCP option right now. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 05:36:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2n0q-0000uX-F1; Wed, 10 Aug 2005 05:36:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2n0o-0000uP-9V for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 05:36:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15995 for ; Wed, 10 Aug 2005 05:36:35 -0400 (EDT) Received: from paddock.ermy.net ([62.189.30.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2nYs-0008VT-A6 for ipv6@ietf.org; Wed, 10 Aug 2005 06:11:51 -0400 Received: (qmail 29839 invoked from network); 10 Aug 2005 09:36:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 10 Aug 2005 09:36:03 -0000 In-Reply-To: References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38268347-7B39-411A-A229-D8122F369692@ecs.soton.ac.uk> Content-Transfer-Encoding: 7bit From: "Mark K. Thompson" Date: Wed, 10 Aug 2005 10:36:03 +0100 To: Arifumi Matsumoto X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, On 9 Aug 2005, at 11:53, Arifumi Matsumoto wrote: > On 2005/08/09, at 5:40, Mark K. Thompson wrote: >> the lack of field definition for labels has seen different OSes >> use different datatypes for the label, from string through >> stringified-integer to integer. Any cross-platform policy >> specification protocol would need to cater for this inconsistency > > By our protocol, we intend to distribute an address selection policy, > of course, but the values in this option aren't absolute but relative. > > When an option includes the following, for example: > > Prefix Precedence Label > 2001:db8::/48 100 10 > 3ffe:db8::/48 20 10 > 2002:1:2::/48 10 5 > > The Label values just indicate that the first line and the second line > has the same label and the third line doesn't have the same label as > any other lines. > This is the case with Precedence value. This option indicates the > order > of precedence. > > So, if a host has its policy table configured manually and has the > label > value 10, the distributed policy's label value should be changed to > another un-used value or string. > > About Precedence, the values in distributed option can be changed > as far as the order isn't changed. > > So, this just seems to me an issue of implementation on DHCPv6 option > receiver. It may be better to clarify these implementation > considerations > in our draft or in another draft. This strikes me as quite non-deterministic and I wonder whether administrators would be happy having pushed-policy being interpreted differently on different nodes depending on their individual state at the point where the policy was received. For example, I can envisage scenarios where administrators want to assert precise control over the contents of the policy table exclusively over any local settings - and that policy may be node- specific as determined by DUID or some Vendor option in DHC. (Assuming that a DHC approach was deemed suitable) Mark/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 23:28:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33jw-0002wv-1Y; Wed, 10 Aug 2005 23:28:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33jt-0002wp-H0 for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 23:28:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20385 for ; Wed, 10 Aug 2005 23:28:15 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E34I6-0006R5-UA for ipv6@ietf.org; Thu, 11 Aug 2005 00:03:40 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRPC8FKSC68Y9VE8@vaxc.its.monash.edu.au> for ipv6@ietf.org; Thu, 11 Aug 2005 13:27:57 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0408BAB54A; Thu, 11 Aug 2005 13:27:57 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id ADD2F4FB03; Thu, 11 Aug 2005 13:27:56 +1000 (EST) Date: Thu, 11 Aug 2005 13:27:56 +1000 From: Greg Daley In-reply-to: <20050810074203.GB583@storhaugen.uninett.no> To: Stig Venaas Message-id: <42FAC5BC.8020104@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <20050810074203.GB583@storhaugen.uninett.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dear Stig, Stig Venaas wrote: > So far two principal solutions have been suggested, RAs and DHCP. If > people want to work on solutions we could possibly look into both of > these. > > Some issues have already been mentioned on this list. Another issue > which was brought up in dhc wg, is that the policy is a host global > config, not per interface. This might be an issue when you have > multiple interfaces. This needs to be considered for both RAs and > DHCP. It's unclear at the moment how a DHCP server on one link is able to describe how to use addresses available on another interface or link. Particularly, it's not clear how the DHCP server can have authority to modify the previously advertised address state from another link, where it isn't responsible for configuration. Given that the policy is based on per interface available addresses, and the host will need to make a combination of these policies anyway, there's little to be gained by assuming the DHCP server is all-knowing about foreign addressing policies. So I don't see the "per-host" argument as convincing at all. > I have two problems with RAs. One is that all hosts on the link will > get the same policy. The other is that I'm worried the policies may > get large, and I'm not sure if it's a good idea to send relatively > large RAs regularly to all the nodes on a link. The Cost in RA is actually completely subsumed by the existing advertisement of Prefix Information Options, which may be augmented (without size modification) by identifying the preference of the particular prefix, for source address selection policies. It is worth noting, that in the DHC proposal, 24 bits of data: (label, precedence, zone-index) are added which aren't present in PIOs. There's an unused 32 octet field available (and another 5 unused bits for flags) in each PIO, which are currently unused. So there's no on-the-medium additional cost. So the only issue is: Does it make sense to use RAs for distributing the default source address preferences to hosts? While it may seem to be a good idea to have different preferences proposed for each host, it's not actually very useful. Hosts can ignore or override the preferences, which is why the policy is described as a default policy in the DHC draft. Considering that the advertised Valid and Preferred Lifetime values for prefixes are per prefix and not per-host, if we're providing routability and stability information to hosts, then the information should likewise be per prefix (not per host). In that case, I guess that PIOs (in RAs) are a good place for them, just like the Valid and Preferred Lifetimes. If the mechanism is being used for some stealthy control of which hosts should use which addresses on the link, I'm against it (since it's unenforceable anyway). I'm also against it if the policy is aimed at being used as a load sharing mechanism (since there are better ways of achieving this). Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 23:33:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33p8-0003Ab-97; Wed, 10 Aug 2005 23:33:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33p5-00039O-GB for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 23:33:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20585 for ; Wed, 10 Aug 2005 23:33:36 -0400 (EDT) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E34NI-0006XD-W2 for ipv6@ietf.org; Thu, 11 Aug 2005 00:09:02 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRPCF8RRX499Q6XN@vaxh.its.monash.edu.au> for ipv6@ietf.org; Thu, 11 Aug 2005 13:33:26 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 63E55AB543; Thu, 11 Aug 2005 13:33:26 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 3122F4FB07; Thu, 11 Aug 2005 13:33:26 +1000 (EST) Date: Thu, 11 Aug 2005 13:33:25 +1000 From: Greg Daley In-reply-to: <20050810091933.GA15594@s51.ath.cx> To: a@arifumi.net Message-id: <42FAC705.6030908@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <001401c59d60$1d1cb8d0$bcf0fea9@S018431> <42F9ABA7.3030404@eng.monash.edu.au> <20050810082345.GD583@storhaugen.uninett.no> <20050810091933.GA15594@s51.ath.cx> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org, Stig Venaas Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi a@arifumi.net wrote: [cut] >>So a question then is whether that is enough or if there are >>many cases where the full policy (including source address >>selection) is needed. If the full policy is needed in some cases, >>then we have to consider whether it's worth having two solutions. >> >>I don't know myself, I think it requires further study. > > > > I myself think that full policy is needed, of course. > > But, even if you define a option only for prefix *preference* > for this framework of policy table, I wonder what the label > value should be. > > As for IPv4 and IPv6 selection, even if you choose an arbitrary > label value, it doesn't have any effects on source address selection. > But, once that option is used for multiple IPv6 prefixes, > the label value has some effects on source address selection also. > > So, as far as you use the policy table framework as it is, > IMHO, you have to distribute prefix preference with label value. It's actually really disappointing that the label field is completely undescribed and (from section 5) "... clients need to convert this label to a representation specified by each implementation (e.g., string)." This is asking for incompatability, and doesn't serve any useful purpose in standardization. Particularly, there's no identification of _which_ implementation the DHCP server intends, especially if it is not aware of the current code version or OS on the host. Perhaps this should be vendor specific information if used in DHC? I can't see any use for it now, and it would need to be strictly specified before providing use any clients. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 23:37:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33t4-0004Zr-Gy; Wed, 10 Aug 2005 23:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33t2-0004WV-8f for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 23:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20923 for ; Wed, 10 Aug 2005 23:37:41 -0400 (EDT) Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E34RG-0006hS-0E for ipv6@ietf.org; Thu, 11 Aug 2005 00:13:07 -0400 Received: from S018431 ([68.160.186.73]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IL100J2UGQQ3K56@vms044.mailsrvcs.net> for ipv6@ietf.org; Wed, 10 Aug 2005 22:37:42 -0500 (CDT) Date: Wed, 10 Aug 2005 23:37:35 -0400 From: "timothy enos" In-reply-to: <42F9ABA7.3030404@eng.monash.edu.au> To: Message-id: <001e01c59e26$06134840$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Stig Venaas' Subject: RE: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Greg, > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Wednesday, August 10, 2005 3:24 AM > To: timothy enos > Cc: 'Stig Venaas'; ipv6@ietf.org > Subject: Re: Distribution of RFC 3484 address selection policies > > Hi Tim, > > timothy enos wrote: > [cut] > >>In that case, I think we > >>should try to look for possible solutions. Some applications might > >>want to specify their own particular behaviour, but I see several > >>reasons why an administrator may want to specify a default. > >> > >>Using DHCP may be one solution. The only alternative available today, > >>is to log into every single host and run each host's OS specific > >>commands to change the policy. This might work for hosts that are > >>centrally administrated at that site. It would not work for hosts > >>visiting that network or under different management. > > > > > > A possibility for the future (realizing it does not presently exist) > > seems to be the creation of a new Router Advertisement option. This > > could be something that would be received and used by clients of both > > DHCPv6 and SLAC. > > > > Using DHCP to distribute RFC 3484 address selection policies would seem > > to work for DHCP clients, yet not for SLAC clients. > > > > I'd guess that it may not be necessary to define a new ND option to > manage the preferences of prefixes, as there are 37 bits unallocated > in the Prefix Information Option (32 bit Reserved2 field + remnant of > Reserved1 field) [RFC3775 S7.2, RFC2461 S4.6.2]. Good point Greg. The 38 unallocated bits spread over the two Reserved fields would seem to be sufficient. I was taking the admittedly somewhat narrow view that the Prefix Information Option was only meant to specify on-link prefixes and/or those that are meant to be used for autoconfiguration (RFC 2461, 4.2). Either using the heretofore unused bits in the Prefix Information Option, or the creation of another option (say, 'Address Selection Option') would be fine with me. > I'd suggest that if preferences are all that's needed, then the > function matches that for which the options are used now. Are preferences all that are needed here? It seems that the question of how hosts would handle such an option also needs to be answered. > Greg Tim 1Sam16:7 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 10 23:37:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33tC-0004aa-II; Wed, 10 Aug 2005 23:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E33tA-0004aV-IK for ipv6@megatron.ietf.org; Wed, 10 Aug 2005 23:37:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20935 for ; Wed, 10 Aug 2005 23:37:50 -0400 (EDT) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E34RO-0006hh-U8 for ipv6@ietf.org; Thu, 11 Aug 2005 00:13:15 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRPCKMSPOE9AQ57D@vaxh.its.monash.edu.au> for ipv6@ietf.org; Thu, 11 Aug 2005 13:37:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2CCC68000E; Thu, 11 Aug 2005 13:37:47 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0FCA63C017; Thu, 11 Aug 2005 13:37:47 +1000 (EST) Date: Thu, 11 Aug 2005 13:37:46 +1000 From: Greg Daley In-reply-to: <38268347-7B39-411A-A229-D8122F369692@ecs.soton.ac.uk> To: "Mark K. Thompson" Message-id: <42FAC80A.9070604@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <38268347-7B39-411A-A229-D8122F369692@ecs.soton.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7BIT Cc: IETF IPv6 Mailing List , Arifumi Matsumoto Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Mark, Mark K. Thompson wrote: > Hi, > > On 9 Aug 2005, at 11:53, Arifumi Matsumoto wrote: > >> On 2005/08/09, at 5:40, Mark K. Thompson wrote: >> >>> the lack of field definition for labels has seen different OSes use >>> different datatypes for the label, from string through >>> stringified-integer to integer. Any cross-platform policy >>> specification protocol would need to cater for this inconsistency >> >> >> By our protocol, we intend to distribute an address selection policy, >> of course, but the values in this option aren't absolute but relative. >> >> When an option includes the following, for example: >> >> Prefix Precedence Label >> 2001:db8::/48 100 10 >> 3ffe:db8::/48 20 10 >> 2002:1:2::/48 10 5 >> >> The Label values just indicate that the first line and the second line >> has the same label and the third line doesn't have the same label as >> any other lines. >> This is the case with Precedence value. This option indicates the order >> of precedence. >> >> So, if a host has its policy table configured manually and has the label >> value 10, the distributed policy's label value should be changed to >> another un-used value or string. >> >> About Precedence, the values in distributed option can be changed >> as far as the order isn't changed. >> >> So, this just seems to me an issue of implementation on DHCPv6 option >> receiver. It may be better to clarify these implementation >> considerations >> in our draft or in another draft. > > > This strikes me as quite non-deterministic and I wonder whether > administrators would be happy having pushed-policy being interpreted > differently on different nodes depending on their individual state at > the point where the policy was received. > > For example, I can envisage scenarios where administrators want to > assert precise control over the contents of the policy table > exclusively over any local settings - and that policy may be node- > specific as determined by DUID or some Vendor option in DHC. (Assuming > that a DHC approach was deemed suitable) I can't see this as particularly useful, and there are better ways (for example PANA address assignment or VPNs) to tie this to the access control state of the host. Otherwise, the control is superficial. Hosts or applications can ignore or reject the advice of the server, and configure what they like. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 00:05:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E34KD-00022E-MZ; Thu, 11 Aug 2005 00:05:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E34KB-000223-Ao for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 00:05:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22029 for ; Thu, 11 Aug 2005 00:05:44 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E34sP-0007Kn-9W for ipv6@ietf.org; Thu, 11 Aug 2005 00:41:10 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2005 21:05:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,98,1122879600"; d="scan'208"; a="5549435:sNHT22561624" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7B45YQl009292; Thu, 11 Aug 2005 00:05:34 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 00:05:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2005 00:05:33 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB217ABFAB@xmb-rtp-20a.amer.cisco.com> Thread-Topic: Solutions for distributing RFC 3484 address selection policies Thread-Index: AcWeJfL6t4fN52tlS9ORdwzseBSVEgAA8CBQ From: "Bernie Volz \(volz\)" To: , "Stig Venaas" X-OriginalArrivalTime: 11 Aug 2005 04:05:34.0338 (UTC) FILETIME=[EC308E20:01C59E29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >It's unclear at the moment how a DHCP server on one link is able >to describe how to use addresses available on another interface >or link. Why would you then assume that an RA on one link could do any more? It too would be restricted to providing policies JUST FOR THAT LINK. I think that's likely all we'd want DHCPv6 to do -- only provide the policies associated with that link? - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Greg Daley > Sent: Wednesday, August 10, 2005 11:28 PM > To: Stig Venaas > Cc: ipv6@ietf.org > Subject: Re: Solutions for distributing RFC 3484 address=20 > selection policies >=20 > Dear Stig, >=20 > Stig Venaas wrote: > > So far two principal solutions have been suggested, RAs and DHCP. If > > people want to work on solutions we could possibly look into both of > > these. > >=20 > > Some issues have already been mentioned on this list. Another issue > > which was brought up in dhc wg, is that the policy is a host global > > config, not per interface. This might be an issue when you have > > multiple interfaces. This needs to be considered for both RAs and > > DHCP. >=20 > It's unclear at the moment how a DHCP server on one link is able > to describe how to use addresses available on another interface > or link. >=20 > Particularly, it's not clear how the DHCP server can have authority > to modify the previously advertised address state from another link, > where it isn't responsible for configuration. >=20 > Given that the policy is based on per interface available addresses, > and the host will need to make a combination of these policies anyway, > there's little to be gained by assuming the DHCP server is all-knowing > about foreign addressing policies. >=20 > So I don't see the "per-host" argument as convincing at all. >=20 > > I have two problems with RAs. One is that all hosts on the link will > > get the same policy. The other is that I'm worried the policies may > > get large, and I'm not sure if it's a good idea to send relatively > > large RAs regularly to all the nodes on a link. >=20 > The Cost in RA is actually completely subsumed by the existing > advertisement of Prefix Information Options, which may be > augmented (without size modification) by identifying the > preference of the particular prefix, for source address > selection policies. >=20 > It is worth noting, that in the DHC proposal, 24 bits of data: > (label, precedence, zone-index) are added which aren't present > in PIOs. >=20 > There's an unused 32 octet field available (and another 5 unused > bits for flags) in each PIO, which are currently unused. >=20 > So there's no on-the-medium additional cost. >=20 >=20 >=20 > So the only issue is: Does it make sense to use RAs for distributing > the default source address preferences to hosts? >=20 > While it may seem to be a good idea to have different preferences > proposed for each host, it's not actually very useful. > Hosts can ignore or override the preferences, which is why > the policy is described as a default policy in the DHC draft. >=20 > Considering that the advertised Valid and Preferred Lifetime values > for prefixes are per prefix and not per-host, if we're providing > routability and stability information to hosts, then the information > should likewise be per prefix (not per host). >=20 > In that case, I guess that PIOs (in RAs) are a good place for them, > just like the Valid and Preferred Lifetimes. >=20 > If the mechanism is being used for some stealthy control of=20 > which hosts > should use which addresses on the link, I'm against it (since it's > unenforceable anyway). I'm also against it if the policy is aimed > at being used as a load sharing mechanism (since there are better ways > of achieving this). >=20 > Greg >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 00:59:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35AT-00037g-8Q; Thu, 11 Aug 2005 00:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35AK-00037Y-QK for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 00:59:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24055 for ; Thu, 11 Aug 2005 00:59:37 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E35iZ-0008RU-57 for ipv6@ietf.org; Thu, 11 Aug 2005 01:35:04 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRPFF0C5668X1QAR@vaxc.its.monash.edu.au> for ipv6@ietf.org; Thu, 11 Aug 2005 14:59:33 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 85F65AB543; Thu, 11 Aug 2005 14:59:32 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 68A8F4FB02; Thu, 11 Aug 2005 14:59:32 +1000 (EST) Date: Thu, 11 Aug 2005 14:59:32 +1000 From: Greg Daley In-reply-to: <8E296595B6471A4689555D5D725EBB217ABFAB@xmb-rtp-20a.amer.cisco.com> To: "Bernie Volz (volz)" Message-id: <42FADB34.6000806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <8E296595B6471A4689555D5D725EBB217ABFAB@xmb-rtp-20a.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org, Stig Venaas Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Bernie. Bernie Volz (volz) wrote: >>It's unclear at the moment how a DHCP server on one link is able >>to describe how to use addresses available on another interface >>or link. > > > Why would you then assume that an RA on one link could do any more? It > too would be restricted to providing policies JUST FOR THAT LINK. > > I think that's likely all we'd want DHCPv6 to do -- only provide the > policies associated with that link? Absolutely. My take is that the issue is the same for DHC and RA. We just need to see whether the usage cases require DHC to specify individual per device (but only for that interface) policies for the host, or whether a general policy for the prefixes available on this link is what's required - regardless of which host device (both DHC and RA could handle this, but my guess is that RA would be neater). Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 01:09:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35Jb-0004wp-KI; Thu, 11 Aug 2005 01:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35JW-0004wf-BI for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 01:09:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24509 for ; Thu, 11 Aug 2005 01:09:09 -0400 (EDT) Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E35rk-0000EH-Qn for ipv6@ietf.org; Thu, 11 Aug 2005 01:44:34 -0400 Received: from S018431 ([68.160.186.73]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IL100HF4KTVW7J1@vms040.mailsrvcs.net> for ipv6@ietf.org; Thu, 11 Aug 2005 00:05:57 -0500 (CDT) Date: Thu, 11 Aug 2005 01:05:52 -0400 From: "timothy enos" In-reply-to: <20050810082345.GD583@storhaugen.uninett.no> To: "'Stig Venaas'" , "'Greg Daley'" Message-id: <002401c59e32$5a40b270$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Stig, > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no] > Sent: Wednesday, August 10, 2005 4:24 AM > To: Greg Daley > Cc: timothy enos; ipv6@ietf.org > Subject: Re: Distribution of RFC 3484 address selection policies >=20 > On Wed, Aug 10, 2005 at 05:24:23PM +1000, Greg Daley wrote: > [...] > > I'd suggest that if preferences are all that's needed, then the > > function matches that for which the options are used now. >=20 > I agree that if only prefix preference is needed (possibly also > v4 vs v6), then it seems obvious to learn this together with the > prefixes themselves.=20 I don't believe that only prefix preference is needed. For mobile nodes, both for source and destination address selection there is home vis-=E0-vis care-of addresses (rule #4). Perhaps also given RFC 3041 section 2.3, source address rule #7 (either to prefer public or temporary) would be needed. For all nodes, it seems that source address selection rule #2 is required: 'Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interop- erability.' (RFC 3484, section 5)=09 > I.e. if you use slaac, then also get the > preference that way (similarly with dhcp or other mechanisms). > The preference is for destination address selection, right? >=20 > So a question then is whether that is enough or if there are > many cases where the full policy (including source address > selection) is needed. I wouldn't agree that all source address selection rules should always be excised from what is distributed.=20 > If the full policy is needed in some cases, > then we have to consider whether it's worth having two solutions. IMO, it doesn't seem necessary to have two solutions, if what is meant by that is to have one for SLAC clients and another for DHCPv6 clients. Using RAs could probably work for both types of clients. =20 > I don't know myself, I think it requires further study. Agreed. > Stig Best regards, Tim 1Sam16:7 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 01:41:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35oy-0002WT-I5; Thu, 11 Aug 2005 01:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35ow-0002WL-0R for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 01:41:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25491 for ; Thu, 11 Aug 2005 01:41:37 -0400 (EDT) Received: from vms048pub.verizon.net ([206.46.252.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E36NB-0000uV-Sc for ipv6@ietf.org; Thu, 11 Aug 2005 02:17:02 -0400 Received: from S018431 ([68.160.186.73]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IL100FS0MFLO7FB@vms048.mailsrvcs.net> for ipv6@ietf.org; Thu, 11 Aug 2005 00:40:35 -0500 (CDT) Date: Thu, 11 Aug 2005 01:40:30 -0400 From: "timothy enos" In-reply-to: <42FAC5BC.8020104@eng.monash.edu.au> To: , "'Stig Venaas'" Message-id: <002501c59e37$30b2a0d0$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Greg/Stig, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Greg Daley > Sent: Wednesday, August 10, 2005 11:28 PM > To: Stig Venaas > Cc: ipv6@ietf.org > Subject: Re: Solutions for distributing RFC 3484 address selection > policies > > Dear Stig, > > Stig Venaas wrote: > > So far two principal solutions have been suggested, RAs and DHCP. If > > people want to work on solutions we could possibly look into both of > > these. > > > > Some issues have already been mentioned on this list. Another issue > > which was brought up in dhc wg, is that the policy is a host global > > config, not per interface. This might be an issue when you have > > multiple interfaces. This needs to be considered for both RAs and > > DHCP. > > It's unclear at the moment how a DHCP server on one link is able > to describe how to use addresses available on another interface > or link. > > Particularly, it's not clear how the DHCP server can have authority > to modify the previously advertised address state from another link, > where it isn't responsible for configuration. > > Given that the policy is based on per interface available addresses, > and the host will need to make a combination of these policies anyway, > there's little to be gained by assuming the DHCP server is all-knowing > about foreign addressing policies. > > So I don't see the "per-host" argument as convincing at all. > > > I have two problems with RAs. One is that all hosts on the link will > > get the same policy. One thing is that in using DHCPv6, all DHCPv6 clients on the link will get the same policy. Also, IMO it wouldn't always be bad for all hosts on a link (DHCPv6 or otherwise) to get the same policy. > The other is that I'm worried the policies may > > get large, and I'm not sure if it's a good idea to send relatively > > large RAs regularly to all the nodes on a link. > > The Cost in RA is actually completely subsumed by the existing > advertisement of Prefix Information Options, which may be > augmented (without size modification) by identifying the > preference of the particular prefix, for source address > selection policies. > > It is worth noting, that in the DHC proposal, 24 bits of data: > (label, precedence, zone-index) are added which aren't present > in PIOs. > > There's an unused 32 octet field available (and another 5 unused > bits for flags) in each PIO, which are currently unused. Actually it's six unused bits in the Reserved1 field of the PIO, but who's counting? :) In the case of flags, it would seem in most cases one bit per rule would do (0=don't implement rule, 1=do implement rule... or something like this). In the cases where there is an option to implement the reverse of a rule (such as is required for rule #7 for source address selection (if it is implemented)), it seems two bits would be needed (00=don't implement this rule, 11=do implement this rule, 01=implement the reverse of this rule... for example). > > So there's no on-the-medium additional cost. > > > > So the only issue is: Does it make sense to use RAs for distributing > the default source address preferences to hosts? > > While it may seem to be a good idea to have different preferences > proposed for each host, it's not actually very useful. > Hosts can ignore or override the preferences, which is why > the policy is described as a default policy in the DHC draft. > > Considering that the advertised Valid and Preferred Lifetime values > for prefixes are per prefix and not per-host, if we're providing > routability and stability information to hosts, then the information > should likewise be per prefix (not per host). Agreed. > In that case, I guess that PIOs (in RAs) are a good place for them, > just like the Valid and Preferred Lifetimes. At least for setting prefix preference, yes RA PIOs are a good place for them. > If the mechanism is being used for some stealthy control of which hosts > should use which addresses on the link, I'm against it (since it's > unenforceable anyway). I'm also against it if the policy is aimed > at being used as a load sharing mechanism (since there are better ways > of achieving this). > > Greg > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 01:55:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E361t-0004q7-QC; Thu, 11 Aug 2005 01:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E361r-0004oO-Jl for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 01:54:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25991 for ; Thu, 11 Aug 2005 01:54:58 -0400 (EDT) Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E36a3-0001CT-BS for ipv6@ietf.org; Thu, 11 Aug 2005 02:30:20 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRPHC3618Q8Y9VHX@vaxc.its.monash.edu.au> for ipv6@ietf.org; Thu, 11 Aug 2005 15:54:27 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BC2DAB545; Thu, 11 Aug 2005 15:54:27 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 070AB4FB0E; Thu, 11 Aug 2005 15:54:27 +1000 (EST) Date: Thu, 11 Aug 2005 15:54:26 +1000 From: Greg Daley In-reply-to: <002501c59e37$30b2a0d0$bcf0fea9@S018431> To: timothy enos Message-id: <42FAE812.3030604@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <002501c59e37$30b2a0d0$bcf0fea9@S018431> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org, 'Stig Venaas' Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Tim, timothy enos wrote: [cut] >>It is worth noting, that in the DHC proposal, 24 bits of data: >>(label, precedence, zone-index) are added which aren't present >>in PIOs. >> >>There's an unused 32 octet field available (and another 5 unused >>bits for flags) in each PIO, which are currently unused. > > > Actually it's six unused bits in the Reserved1 field of the PIO, but > who's counting? :) Mobile IPv6 [ as referred previously: RFC3775, Section 7.2]. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 06:06:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E39wq-0006UW-0N; Thu, 11 Aug 2005 06:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E39wm-0006UD-Q0 for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 06:06:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20867 for ; Thu, 11 Aug 2005 06:05:58 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3AV4-0007zz-Fh for ipv6@ietf.org; Thu, 11 Aug 2005 06:41:27 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7BA5dTb012980; Thu, 11 Aug 2005 12:05:39 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7BA5dGs008559; Thu, 11 Aug 2005 12:05:39 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7BA5dGF008558; Thu, 11 Aug 2005 12:05:39 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 11 Aug 2005 12:05:39 +0200 From: Stig Venaas To: Greg Daley Message-ID: <20050811100539.GA8387@storhaugen.uninett.no> References: <20050810074203.GB583@storhaugen.uninett.no> <42FAC5BC.8020104@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42FAC5BC.8020104@eng.monash.edu.au> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ipv6@ietf.org Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Dear Greg, On Thu, Aug 11, 2005 at 01:27:56PM +1000, Greg Daley wrote: > Dear Stig, > > Stig Venaas wrote: > >So far two principal solutions have been suggested, RAs and DHCP. If > >people want to work on solutions we could possibly look into both of > >these. > > > >Some issues have already been mentioned on this list. Another issue > >which was brought up in dhc wg, is that the policy is a host global > >config, not per interface. This might be an issue when you have > >multiple interfaces. This needs to be considered for both RAs and > >DHCP. > > It's unclear at the moment how a DHCP server on one link is able > to describe how to use addresses available on another interface > or link. > > Particularly, it's not clear how the DHCP server can have authority > to modify the previously advertised address state from another link, > where it isn't responsible for configuration. > > Given that the policy is based on per interface available addresses, > and the host will need to make a combination of these policies anyway, > there's little to be gained by assuming the DHCP server is all-knowing > about foreign addressing policies. > > So I don't see the "per-host" argument as convincing at all. It seems we are discussing very different things here. You are talking of prioritizing the prefixes announced on the link(s) so that the host can use these to influence source address selection, right? In that case I agree that it makes sense to pass the priority along with the prefixes of course. The 3484 policy table however allows much more than that. It allows destination address selection in which case you want to have some preference among prefixes that are not prefixes for the link where the client is. 3484 also allows preference of IPv4 vs IPv6. That policy would be more awkward to pass in RAs, and isn't necessarily for one particular link. > >I have two problems with RAs. One is that all hosts on the link will > >get the same policy. The other is that I'm worried the policies may > >get large, and I'm not sure if it's a good idea to send relatively > >large RAs regularly to all the nodes on a link. > > The Cost in RA is actually completely subsumed by the existing > advertisement of Prefix Information Options, which may be > augmented (without size modification) by identifying the > preference of the particular prefix, for source address > selection policies. For preference amongst the prefixes on the link, yes. > It is worth noting, that in the DHC proposal, 24 bits of data: > (label, precedence, zone-index) are added which aren't present > in PIOs. But as I said, this does much more. E.g. the label is for destination address selection. You're comparing apples and oranges here. > There's an unused 32 octet field available (and another 5 unused > bits for flags) in each PIO, which are currently unused. > > So there's no on-the-medium additional cost. > > > > So the only issue is: Does it make sense to use RAs for distributing > the default source address preferences to hosts? > > While it may seem to be a good idea to have different preferences > proposed for each host, it's not actually very useful. > Hosts can ignore or override the preferences, which is why > the policy is described as a default policy in the DHC draft. I'm sure there are different views on that. I would like a site administrator to specify behaviour of the hosts in the site without having to manage each host separately. So I want hosts generally to use exactly the specified policy. This is also why I want to allow for different hosts on a link to be told to have different policies. Certainly there might still be ways for a host to override the policy though. > Considering that the advertised Valid and Preferred Lifetime values > for prefixes are per prefix and not per-host, if we're providing > routability and stability information to hosts, then the information > should likewise be per prefix (not per host). For prefix preference which you're talking about I agree. > In that case, I guess that PIOs (in RAs) are a good place for them, > just like the Valid and Preferred Lifetimes. > > If the mechanism is being used for some stealthy control of which hosts > should use which addresses on the link, I'm against it (since it's > unenforceable anyway). I'm also against it if the policy is aimed > at being used as a load sharing mechanism (since there are better ways > of achieving this). Neither of these are what I have in mind. For some possible uses of 3484, see http://www.nttv6.net/dass/ Might be good idea to discuss how to prioritize prefixes (and I assume source address selection) and uses for that, independently of what 3484 can solve and how that can be used. There is of course overlap. I would be interested to see how you want your solution to work wrt source and destination address selection. Do you imagine doing destination and interface selection first, and then use this to pick source address? Or do you want this in some way to influence destination address selection as well. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 07:23:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3B9H-0007No-TW; Thu, 11 Aug 2005 07:22:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3B9F-0007NX-9q for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 07:22:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24156 for ; Thu, 11 Aug 2005 07:22:56 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3BhW-0001Ub-MG for ipv6@ietf.org; Thu, 11 Aug 2005 07:58:24 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7BBMaqA002130 for ; Thu, 11 Aug 2005 12:22:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA19133 for ; Thu, 11 Aug 2005 12:21:52 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7BBLqk23504 for ipv6@ietf.org; Thu, 11 Aug 2005 12:21:52 +0100 Date: Thu, 11 Aug 2005 12:21:52 +0100 From: Tim Chown To: IETF IPv6 Mailing List Message-ID: <20050811112152.GG21632@login.ecs.soton.ac.uk> Mail-Followup-To: IETF IPv6 Mailing List References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F813F3.7050005@eng.monash.edu.au> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Tue, Aug 09, 2005 at 12:24:51PM +1000, Greg Daley wrote: > > I'm not sure anyone is doing it, but renumbering is applicable > there as a means of providing information about which prefixes > are valid. We went through a pretty full enterprise renumbering procedure, but were able to control address selection purely through RAs, to indicate the deprecated status where multiple prefixes were advertised. This worked well - address selection was correct on XP, Linux, MacOS and Solaris. Purely for renumbering, RA indications may suffice. There is however, much greater complexity to managing a renumbering event, as Fred described. > I'd guess that any mechanism which interacted with router discovery > to provide address selection policy would need to be integrated with > the ND messages, and the configuration systems applicable to those > messages. There's a few comments I'd make on this (very interesting) thread. It is important that we consider source and destination address selection, i.e. full 3484 policy. We also need to support non-prefix based policy, like whether privacy addresses should be used. As an enterprise admin, I see 3041 as adding a lot of management complexity for little gain (though as a roaming IPv6 user, my view is different :). I don't think the suggested method off 'adding the /128 into the table' cuts it. We also probably would like v4 vs v6 preference too. This has to be done in the knowledge that applications may be trying to make their own choices via APIs here. As an admin, I like DHC as a proposed solution. We've already seen pushback on bloating RAs, e.g. for DNS resolver discovery. I think the DHC-based draft is flawed if it is adding policy not replacing policy - especially where new 'random' labels are being generated where clashes exist. I would like an absolute policy distribution. Greg points out that the hosts may ignore it, but the hosts can ignore allocated addresses too the way many enterprises are run :) I thinka DHC server offlink can give the information... relay agents can handle that? I'd rather have policy configured in one DHC service, or did I misunderstand? Having a per host policy capability would be nice. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 09:06:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Cl4-0003Ya-1f; Thu, 11 Aug 2005 09:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Cky-0003Wg-QQ for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 09:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29663 for ; Thu, 11 Aug 2005 09:05:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3DJH-0004Ci-35 for ipv6@ietf.org; Thu, 11 Aug 2005 09:41:28 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2005 09:05:45 -0400 X-IronPort-AV: i="3.96,100,1122868800"; d="scan'208"; a="66131543:sNHT30107940" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7BD5fT8008712 for ; Thu, 11 Aug 2005 09:05:43 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 09:05:33 -0400 Received: from 10.86.240.140 ([10.86.240.140]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Aug 2005 13:06:00 +0000 Received: from localhost.localdomain by email.cisco.com; 11 Aug 2005 09:06:40 -0400 From: Ralph Droms To: IETF IPv6 Mailing List In-Reply-To: <20050811112152.GG21632@login.ecs.soton.ac.uk> References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> <20050811112152.GG21632@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 11 Aug 2005 09:06:40 -0400 Message-Id: <1123765600.5497.35.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 11 Aug 2005 13:05:33.0482 (UTC) FILETIME=[5B9598A0:01C59E75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Seems to me the WG ought to work through these questions: 1. Is RFC 3484 adequate to solve the address selection problem? My guess is "no", because of its references to site-local addresses and other deficiencies discussed in this thread. If the answer is no, the first step for the WG would be to update RFC 3484. 2. Is there a requirement for automated/administered management of the address selection policy specified in RFC 3484 (or RFC 3484bis) in hosts? Seems like there is enough interest in this thread for policy management to warrant WG activity... 3. What are the right semantics and the right vehicle for providing management? TBD, once we get answers to 1 and 2? - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 10:03:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DeR-00082i-6q; Thu, 11 Aug 2005 10:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3DeO-00082d-Pw for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 10:03:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03167 for ; Thu, 11 Aug 2005 10:03:15 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ECh-0005gz-T4 for ipv6@ietf.org; Thu, 11 Aug 2005 10:38:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2005 07:02:54 -0700 X-IronPort-AV: i="3.96,100,1122879600"; d="scan'208"; a="654274171:sNHT973569096" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7BE21pM006990; Thu, 11 Aug 2005 07:02:51 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 10:02:50 -0400 Received: from 10.86.240.140 ([10.86.240.140]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Aug 2005 14:03:26 +0000 Received: from localhost.localdomain by email.cisco.com; 11 Aug 2005 10:03:57 -0400 From: Ralph Droms To: timothy enos In-Reply-To: <002501c59e37$30b2a0d0$bcf0fea9@S018431> References: <002501c59e37$30b2a0d0$bcf0fea9@S018431> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 11 Aug 2005 10:03:57 -0400 Message-Id: <1123769037.5497.41.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 11 Aug 2005 14:02:50.0458 (UTC) FILETIME=[5C2E83A0:01C59E7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Stig Venaas' , greg.daley@eng.monash.edu.au Subject: RE: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 2005-08-11 at 01:40 -0400, timothy enos wrote: > [...] > One thing is that in using DHCPv6, all DHCPv6 clients on the link will > get the same policy. Also, IMO it wouldn't always be bad for all hosts > on a link (DHCPv6 or otherwise) to get the same policy. It's not the case that all DHCPv6 clients on a link need to be configured with the same policy; the DHCPv6 server can return a specific (and potentially different) policy for each client. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 10:19:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Dtu-00047C-E9; Thu, 11 Aug 2005 10:19:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Dts-000473-Fd for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 10:19:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04926 for ; Thu, 11 Aug 2005 10:19:14 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ESB-00067u-6w for ipv6@ietf.org; Thu, 11 Aug 2005 10:54:44 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7BEJ7qA006610 for ; Thu, 11 Aug 2005 15:19:07 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA02595 for ; Thu, 11 Aug 2005 15:18:33 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7BEIXt28171 for ipv6@ietf.org; Thu, 11 Aug 2005 15:18:33 +0100 Date: Thu, 11 Aug 2005 15:18:33 +0100 From: Tim Chown To: IETF IPv6 Mailing List Message-ID: <20050811141833.GO21632@login.ecs.soton.ac.uk> Mail-Followup-To: IETF IPv6 Mailing List References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> <20050811112152.GG21632@login.ecs.soton.ac.uk> <1123765600.5497.35.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1123765600.5497.35.camel@localhost.localdomain> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Aug 11, 2005 at 09:06:40AM -0400, Ralph Droms wrote: > Seems to me the WG ought to work through these questions: > > 1. Is RFC 3484 adequate to solve the address selection problem? > > My guess is "no", because of its references to site-local addresses and > other deficiencies discussed in this thread. If the answer is no, the > first step for the WG would be to update RFC 3484. Rich seemed amenable to this when asked recently. In doing so, we should review default policy to minimise the requirement to change policy, e.g. fix the corner cases like ULAs+multicast being broken. -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 10:51:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EOy-0003cG-4X; Thu, 11 Aug 2005 10:51:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EOw-0003cA-8A for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 10:51:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07180 for ; Thu, 11 Aug 2005 10:51:20 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ExF-00070L-Qj for ipv6@ietf.org; Thu, 11 Aug 2005 11:26:51 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7BEp7Tb019206 for ; Thu, 11 Aug 2005 16:51:08 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7BEp7bs010032 for ; Thu, 11 Aug 2005 16:51:07 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7BEp7Hv010031 for ipv6@ietf.org; Thu, 11 Aug 2005 16:51:07 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 11 Aug 2005 16:51:07 +0200 From: Stig Venaas To: IETF IPv6 Mailing List Message-ID: <20050811145107.GQ8387@storhaugen.uninett.no> References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> <20050811112152.GG21632@login.ecs.soton.ac.uk> <1123765600.5497.35.camel@localhost.localdomain> <20050811141833.GO21632@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050811141833.GO21632@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Aug 11, 2005 at 03:18:33PM +0100, Tim Chown wrote: > On Thu, Aug 11, 2005 at 09:06:40AM -0400, Ralph Droms wrote: > > Seems to me the WG ought to work through these questions: > > > > 1. Is RFC 3484 adequate to solve the address selection problem? > > > > My guess is "no", because of its references to site-local addresses and > > other deficiencies discussed in this thread. If the answer is no, the > > first step for the WG would be to update RFC 3484. > > Rich seemed amenable to this when asked recently. In doing so, we > should review default policy to minimise the requirement to change > policy, e.g. fix the corner cases like ULAs+multicast being broken. Also worth checking if there are address selection problems that 3484 doesn't address. Stig > > -- > Tim/::1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 10:57:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EUz-0005Fv-4n; Thu, 11 Aug 2005 10:57:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EUx-0005Fq-2S for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 10:57:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07417 for ; Thu, 11 Aug 2005 10:57:33 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3F3G-00079a-Fi for ipv6@ietf.org; Thu, 11 Aug 2005 11:33:04 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2005 07:57:22 -0700 X-IronPort-AV: i="3.96,100,1122879600"; d="scan'208"; a="331240605:sNHT32128960" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7BEuu0b003459 for ; Thu, 11 Aug 2005 07:57:20 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 10:57:09 -0400 Received: from 10.86.240.140 ([10.86.240.140]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Aug 2005 14:57:11 +0000 Received: from localhost.localdomain by email.cisco.com; 11 Aug 2005 10:58:16 -0400 From: Ralph Droms To: IETF IPv6 Mailing List In-Reply-To: <20050811145107.GQ8387@storhaugen.uninett.no> References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> <20050811112152.GG21632@login.ecs.soton.ac.uk> <1123765600.5497.35.camel@localhost.localdomain> <20050811141833.GO21632@login.ecs.soton.ac.uk> <20050811145107.GQ8387@storhaugen.uninett.no> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 11 Aug 2005 10:58:15 -0400 Message-Id: <1123772296.5497.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 11 Aug 2005 14:57:09.0198 (UTC) FILETIME=[F28AC6E0:01C59E84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, 2005-08-11 at 16:51 +0200, Stig Venaas wrote: > On Thu, Aug 11, 2005 at 03:18:33PM +0100, Tim Chown wrote: > > On Thu, Aug 11, 2005 at 09:06:40AM -0400, Ralph Droms wrote: > > > Seems to me the WG ought to work through these questions: > > > > > > 1. Is RFC 3484 adequate to solve the address selection problem? > > > > > > My guess is "no", because of its references to site-local addresses and > > > other deficiencies discussed in this thread. If the answer is no, the > > > first step for the WG would be to update RFC 3484. > > > > Rich seemed amenable to this when asked recently. In doing so, we > > should review default policy to minimise the requirement to change > > policy, e.g. fix the corner cases like ULAs+multicast being broken. > > Also worth checking if there are address selection problems that 3484 > doesn't address. > > Stig Mark Thompson pointed out: > > First, the lack of field definition for labels has seen different > OSes use different datatypes for the label, from string through > stringified-integer to integer. Any cross-platform policy > specification protocol would need to cater for this inconsistency. > Perhaps this is something that a RFC3484-bis could address when > making that spec compliant with the requirements of RFC3879 Section 4? > > Also, RFC3484 permits the specification of zone index in the policy > (c.f section 2.1). Section 6 of RFC4007 explicitly states that zone > indices are strictly local to the node, making any centralisation of > RFC3484 policy "challenging". [aside: OK, so administrators could > harvest index data for links on which scoped-policy is required and > then maintained in the DHCPv6 server as specific for that node, but > there's no protocol for that harvesting and I've not surveyed > sufficient implementations to determine whether indexes persist and > are consistent between reboots] - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 11:00:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EXJ-0005an-E5; Thu, 11 Aug 2005 11:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EXG-0005aN-Ab for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 10:59:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07541 for ; Thu, 11 Aug 2005 10:59:55 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3F5Z-0007Ef-J4 for ipv6@ietf.org; Thu, 11 Aug 2005 11:35:27 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7BExsqA007640 for ; Thu, 11 Aug 2005 15:59:54 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA06337 for ; Thu, 11 Aug 2005 15:59:11 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7BExB629516 for ipv6@ietf.org; Thu, 11 Aug 2005 15:59:11 +0100 Date: Thu, 11 Aug 2005 15:59:11 +0100 From: Tim Chown To: IETF IPv6 Mailing List Message-ID: <20050811145911.GT21632@login.ecs.soton.ac.uk> Mail-Followup-To: IETF IPv6 Mailing List References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> <20050811112152.GG21632@login.ecs.soton.ac.uk> <1123765600.5497.35.camel@localhost.localdomain> <20050811141833.GO21632@login.ecs.soton.ac.uk> <20050811145107.GQ8387@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050811145107.GQ8387@storhaugen.uninett.no> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Aug 11, 2005 at 04:51:07PM +0200, Stig Venaas wrote: > On Thu, Aug 11, 2005 at 03:18:33PM +0100, Tim Chown wrote: > > On Thu, Aug 11, 2005 at 09:06:40AM -0400, Ralph Droms wrote: > > > Seems to me the WG ought to work through these questions: > > > > > > 1. Is RFC 3484 adequate to solve the address selection problem? > > > > > > My guess is "no", because of its references to site-local addresses and > > > other deficiencies discussed in this thread. If the answer is no, the > > > first step for the WG would be to update RFC 3484. > > > > Rich seemed amenable to this when asked recently. In doing so, we > > should review default policy to minimise the requirement to change > > policy, e.g. fix the corner cases like ULAs+multicast being broken. > > Also worth checking if there are address selection problems that 3484 > doesn't address. Like selecting privacy addresses? -- Tim/::1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 11:12:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Eiz-0000eS-B7; Thu, 11 Aug 2005 11:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Eix-0000eH-9n for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 11:12:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08255 for ; Thu, 11 Aug 2005 11:12:01 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3FHG-0007aX-SM for ipv6@ietf.org; Thu, 11 Aug 2005 11:47:32 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7BFC0Tb024123 for ; Thu, 11 Aug 2005 17:12:00 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7BFC0VX010120 for ; Thu, 11 Aug 2005 17:12:00 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7BFC0jV010119 for ipv6@ietf.org; Thu, 11 Aug 2005 17:12:00 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 11 Aug 2005 17:12:00 +0200 From: Stig Venaas To: IETF IPv6 Mailing List Message-ID: <20050811151200.GS8387@storhaugen.uninett.no> References: <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <42F7F18E.2000102@eng.monash.edu.au> <42F813F3.7050005@eng.monash.edu.au> <20050811112152.GG21632@login.ecs.soton.ac.uk> <1123765600.5497.35.camel@localhost.localdomain> <20050811141833.GO21632@login.ecs.soton.ac.uk> <20050811145107.GQ8387@storhaugen.uninett.no> <20050811145911.GT21632@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050811145911.GT21632@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: Re: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org On Thu, Aug 11, 2005 at 03:59:11PM +0100, Tim Chown wrote: > On Thu, Aug 11, 2005 at 04:51:07PM +0200, Stig Venaas wrote: > > Also worth checking if there are address selection problems that 3484 > > doesn't address. > > Like selecting privacy addresses? My feeling is that it's sufficient to disable/enable. Or is there really a need for using privacy source addresses for some destinations and not others? I think it's good if the policy is a bit generic, i.e. avoiding literal naming of the hosts addresses (possibly prefixes) when possible. I don't how it could be done, but some solution that means the policy is valid independent of which particular prefixes are on a link at a given time (and what privacy addresses the host has). Maybe helps to use some sort of tokens in the policy? Something like LINK_PREFIXES, MY_PRIVATE_ADDRESSES, MY_PUBLIC_ADDRESSES, MY_ULA_ADDRESSES. But again, I don't really know if it could work, and if it's work doing. I think it's something to consider though. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 11:38:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3F8l-0006Se-DC; Thu, 11 Aug 2005 11:38:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3F8g-0006SL-Mm for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 11:38:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09845 for ; Thu, 11 Aug 2005 11:38:36 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Fgx-0008NQ-Jj for ipv6@ietf.org; Thu, 11 Aug 2005 12:14:08 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:18b0:8517:3eb2:df]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2019D15218; Fri, 12 Aug 2005 00:38:25 +0900 (JST) Date: Fri, 12 Aug 2005 00:38:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@sun.com, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: ipv6@ietf.org Subject: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org As requested, here are my comments about the addrselect-api draft. First of all, I must say I'm not particularly fascinated by this API. As (I think) I said before, I believe this can be useful in very limited situations only (especially because applications need to be modified - I generally agree with Francis on this point), and most applications (and application writers) wouldn't be bothered with using the additional feature. In fact, the only people I've ever seen who expressed interest in this API are mobile IP(v6) implementors, expecting this API can be used in their mobile IP(v6) specific implementations (e.g., ones that negotiate with the home agent). I respect that the draft provides one section showing usage examples, but these are not convincing enough to me. But I hear that the IPv6 chairs admitted this document to be published as an individual RFC, and so I won't insist this point further. Specific comments follows: SUBSTANTIAL COMMENTS 1. I'm (still) not convinced that we need two flags for each single rule (e.g., IPV6_PREFER_SRC_TMP and IPV6_PREFER_SRC_PUBLIC for whether to prefer temporary addresses). As we see in the current API proposal, introduces invalid combinations, making error handling more complex. It also consumes more bits (see comment #2 below) from the limited space. I'd rather prefer a single flag bit for each rule. For example, we'd only need IPV6_PREFER_SRC_TMP: if this is set, we prefer temporary addresses; if not set, we prefer public addresses. According to the draft, the main reason for having two bits is to allow different implementations to have different system default. But I believe we could deal with this with a single bit. Again, as mentioned in the draft, we can do this with a single bit for the socket option. Then we should be able to apply the same default for the getaddrinfo, since if the system default for the socket option were different from that for getaddrinfo it would not work as intended anyway (at least for source address selection). In addition (or alternatively) we might be able to define something like "AI_DEFAULT" (which was in fact defined in RFC2553), containing the implementation default values, particularly for destination address selection. 2. I'm concerned about defining (yet other) family-specific flags for getaddrinfo() for two reasons. First, such flags would be against the sense of "protocol-independentness" of this function. Second, those consume the relatively scarce bit field just for one particular protocol. Regarding the first point, one may point out RFC3493 also define AF_INET6-specific flags: AI_V4MAPPED and AI_ALL. That's true (unfortunately), but IMO we should not use the fact as an excuse for introducing further violation. As for the second point, ai_flags is an 'int' member as per RFC3493, which can contain at most 32 flags for today's most systems. There may even be systems where getaddrinfo() is provided and the 'int' type is a 16-bit integer. RFC3493 already defines 7 flags for this member, and the current proposal of this API is going to add 10 more. So this API wouldn't work if 'int' is a 16bit integer. I'm also concerned about the fact that this API consumes nearly one third of the available flags even for 32-bit systems, particularly for one specific protocol. So, if possible, I'd like to realize the API's goal without messing ai_flags further. I admit this would be difficult in the current interface to getaddrinfo() though. At least I don't have a clear idea about how to do that. Possible random thoughts at this moment (while those are not a perfect solution) include: - reduce the number of additional flags by the '1 flag per rule' approach (comment #1) - add another member to the addrinfo structure for additional (particularly protocol dependent) flags. note that we could do this without breaking (binary) backward compatibility since multiple addrinfo structure are combined as a linked list. - allow the 'hints' structure to have 'next' entries where protocol dependent flags are defined (although this does not work on *BSD's implementation since it requires hints->ai_next be NULL) 3. I suspect the necessity of IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE. Those might actually be even harmful. The API draft says these correspond to Rule 2 of the source address selection defined in RFC3484. But the RFC says: Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability. Is it really okay to provide an easy knob for applications to "reverse" the logic despite the strong requirement? And, I'm actually not sure in which (practical) case we want to specify the non default rule. The last paragraph of Section 3 provides an example, but it's not very specific, and cannot be used as a practical example. At the very least, I'm not even sure how the logic of Rule 2 is modified if we specify IPV6_PREFER_SRC_SCOPE. The rule defined in RFC3484 is: Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. How would this look like with IPV6_PREFER_SRC_SCOPE? At the moment, my primary suggestion is to remove IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE. If we really want to keep those, I'd request the semantics be defined much more clearly. [Note: I can see the meaning and the usage of AI_PREFER_SRC_{SMALL,LARGE}SCOPE for destination address selection. In fact, this is another example why these IPV6_xxx and AI_xxx sets cannot necessarily be corresponding.] SEMI SUBSTANTIAL COMMENTS 4. Considering the background motivation of the advanced API, I think we should also provide an ancillary-data object corresponding to the proposed socket option in order to control the address selection policy per-packet basis with a single system call (i.e., sendmsg()). 5. (AFAICS) This document does not explicitly define the return value of getsockopt(IPV6_ADDR_PREFERENCES). Even though it's pretty trivial, I believe an API specification should generally provide such 'trivial' things very clearly and explicitly. 6. [1st line of page 4 (continued from page 3)] [...] Since source address selection and destination address ordering need to be partially implemented in getaddrinfo() [3] the corresponding set of flags are also defined for that routine. I think this is too strong. Although destination address ordering (selection) would typically be implemented through getaddrinfo(), the selection rules themselves are quite general and could be realized in some other way. 7. [3rd paragraph of Section 5] [...] Thus when AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and SA before SB likewise. I don't understand this sentence. What does 'and SA before SB likewise' mean? 8. [page 12 (Section 5), just after the flag list] The above flags are ignored for the AF_INET address family as the address selection algorithm defined in section 5 of [1] only applies to the IPv6 addresses. This is not really true. RFC3484's destination address selection considers both IPv4 and IPv6 addresses (See Section 3.2 of RFC3484). Besides, even if RFC3484 only considered IPv6 addresses, the API statement would still not be very accurate: what if we have IPv9?:-) 9. [first paragraph of Section 6] An application only needs to call getsockopt() prior calling setsockopt() if the application needs to be able to restore the socket back to the system default preferences. This seems odd. Shouldn't the application just be able to reset the rules to the default by specifying the all-0 flags? If not, why do we need the sets of two flags to begin with? 10. [second code fragment shown in Section 6] This does not seem to be very accuratete or consistent. According to manual pages (available around me), the third arguments of getsockopt() and setsockopt() are 'void *' and 'const void *', respectively. On the other hand, this example code casts the arguments to setsockopt() as 'char *' while it simply passes 'uint32_t *' to getaddrinfo(). If we ignore minor type-matching issues for brevity, I'd simply remove all the cast. If we're willing to show casting for accuracy, we should be consistent and use accurate casting for all the examples. 11. [second to last paragraph of Section 6] In order to allow different implementations to do different parts of address selection in getaddrinfo() and in the protocol stack, this specification requires that applications set the same flags when calling getaddrinfo() and when calling setsockopt(). For example, if the application sets IPV6_PREFER_SRC_COA flag, it must use AI_PREFER_SRC_COA flag when calling getaddrinfo(). If applications are not setting the same flags the behavior of the implementation is undefined. The phrase of "the same flags" (there are two occurrences) is not very accurate, since these are actually different, at least as macro names. 12. [second bullet of Section 7] What would getsockopt() return for preference flags that are not supported in the system? (see also comment #5) 13. [third bullet of Section 7] If an implementation supports both stream and datagram sockets, it should implement the address preference mechanism API described in this document on types of sockets. I simply don't understand what this means...could you elaborate? (BTW: perhaps 'on types of sockets' should be 'based on types of sockets'? Even if so, I still don't understand what this means, though) 14. [second to last paragraph of Section 8] Other destination rules (#4-prefer home address; #7-prefer native interfaces) could have been applicable. But the problem is that the local system does not know whether a destination address is a tunnel- address for destination rule #7. It can only know for sure if the destination address is one of its own. I don't think this is really correct. First, destination rule #7 is 'Prefer native transport' not 'interfaces'. Second, the implementation can syntacatically identify 'non-native' destinations in some cases (e.g., for 6to4 addresses). Third, at least in theory, the local implementation (even an application) could identify the outgoing interface for a given destination, and might be able to identify it's a tunneling interface. I do not necessarily require this API consider destination rule #7, but the "excuse" for not doing so should be accurate and convincing. 15. [Section 10] Do we really need (standardize) a separate function like inet6_is_srcaddr()? Perhaps I'm pretty dubious about this just because I'm dubious about the usefulness of the entire API in the first place, but I'd suggest confirming this point with other implementers, particularly with those who are interested in this API. 16. [last paragraph of page 20] The function returns true when srcaddr corresponds to a valid address in the node and that address type satisfies the preference flag(s). I don't think 'that address type satisfies the preference flag' is well-defined, although it is intuitively understandable. Please be more precise (c.f. comment #5). There may actually be subtle cases: e.g., what does it mean if I specify IPV6_PREFER_SRC_SMALLSCOPE as 'flags'? That is, 'small' is only meaningful when we are comparing multiple things, while this function takes only one address. I suspect this indicates we should reconsider the function design. 17. [regarding inet6_is_srcaddr() in general] If we really need this function (see comment #15), I believe we should clearly separate error cases, i.e., we should not overload the 'false' return value. This might sound a matter of taste, but I believe it's a common and well-known practice. PURELY EDITORIAL COMMENTS 18. [first bullet of Section 2] o While some system have per environment/application flags (such as environment variables in Unix systems) this might not be available in all systems which implement the socket API => s/some system have/some systems have/ 19. [last sentence of page 9] The following example illustrates how it is used on a AF_INET6 socket: => s/a AF_INET6/an AF_INET6/ 20. [overall] There is a mixture of 'Care-of' (even not at the BOL), 'care-of', 'Care-Of' and 'Care-of' (and perhaps more). There are even some odd forms like "Care-Of_address" or "care-of -address". Those should be unified. 21. [overall] There are some redundant white space after opening parenthesis. For example, Destination address selection rule #8 ( prefer smaller scope): (page 17) Those should be removed. 22. [first line of page 21] or it does not match an address which satisfy the preferences indicated, the function returns false. => s/satisfy/satisfies/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 15:28:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Iiw-00008S-Tq; Thu, 11 Aug 2005 15:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Iis-0008Vd-Bb; Thu, 11 Aug 2005 15:28:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22135; Thu, 11 Aug 2005 15:28:12 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3JHF-0006BG-Er; Thu, 11 Aug 2005 16:03:45 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E3Iip-0002V5-Hn; Thu, 11 Aug 2005 15:28:11 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 11 Aug 2005 15:28:11 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification' to Draft Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org The IESG has approved the following document: - 'Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification ' as a Draft Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-07.txt Technical Summary This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). This is an update to RFC 2463 (currently a Draft Standard) with minor changes and bug fixes based on implementation and deployment experience. The changes are well-described in Appendix A of the document. Working Group Summary This document is a work item of the IPv6 WG. Protocol Quality ICMPv6 has been extensively implemented and successfully deployed. This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 19:22:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MNd-0000w8-AU; Thu, 11 Aug 2005 19:22:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MNb-0000w0-2z for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 19:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05943 for ; Thu, 11 Aug 2005 19:22:26 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Mvu-00047f-5N for ipv6@ietf.org; Thu, 11 Aug 2005 19:58:02 -0400 Received: from jurassic.eng.sun.com ([129.146.68.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7BNMJvU019822; Thu, 11 Aug 2005 17:22:19 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j7BNMIkD239375; Thu, 11 Aug 2005 16:22:19 -0700 (PDT) Message-Id: <200508112322.j7BNMIkD239375@jurassic.eng.sun.com> Date: Thu, 11 Aug 2005 16:21:02 -0700 (PDT) From: Samita Chakrabarti To: jinmei@isl.rdc.toshiba.co.jp MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PXWa8Lb/fnv3ZakoqtIEZg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: erik.nordmark@sun.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Jinmei, > As requested, here are my comments about the addrselect-api draft. > > First of all, I must say I'm not particularly fascinated by this API. > As (I think) I said before, I believe this can be useful in very > limited situations only (especially because applications need to be > modified - I generally agree with Francis on this point), and most > applications (and application writers) wouldn't be bothered with using > the additional feature. In fact, the only people I've ever seen who > expressed interest in this API are mobile IP(v6) implementors, > expecting this API can be used in their mobile IP(v6) specific > implementations (e.g., ones that negotiate with the home agent). I > respect that the draft provides one section showing usage examples, > but these are not convincing enough to me. Yes, this document would be useful for IP mobility aware applications. > But I hear that the IPv6 chairs admitted this document to be published > as an individual RFC, and so I won't insist this point further. > This document is targeting for an individual RFC. Thanks for the timely comments. After receiving the designated individual comments, the draft authors will go through the issues and comments, and will reply on the list, in a few weeks. Regards, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 20:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NCd-0002ao-UZ; Thu, 11 Aug 2005 20:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NCb-0002ac-TA for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 20:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07963 for ; Thu, 11 Aug 2005 20:15:12 -0400 (EDT) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Nl1-00068l-DG for ipv6@ietf.org; Thu, 11 Aug 2005 20:50:47 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRQJRF13WU9APZMX@vaxh.its.monash.edu.au> for ipv6@ietf.org; Fri, 12 Aug 2005 10:14:52 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E9E5DAB546; Fri, 12 Aug 2005 10:14:51 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id C73764FB05; Fri, 12 Aug 2005 10:14:51 +1000 (EST) Date: Fri, 12 Aug 2005 10:14:51 +1000 From: Greg Daley In-reply-to: <1123769037.5497.41.camel@localhost.localdomain> To: Ralph Droms Message-id: <42FBE9FB.6020005@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <002501c59e37$30b2a0d0$bcf0fea9@S018431> <1123769037.5497.41.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org, 'Stig Venaas' Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Ralph, Ralph Droms wrote: > On Thu, 2005-08-11 at 01:40 -0400, timothy enos wrote: > >>[...] >>One thing is that in using DHCPv6, all DHCPv6 clients on the link will >>get the same policy. Also, IMO it wouldn't always be bad for all hosts >>on a link (DHCPv6 or otherwise) to get the same policy. > > > It's not the case that all DHCPv6 clients on a link need to be > configured with the same policy; the DHCPv6 server can return a specific > (and potentially different) policy for each client. I agree that this is possible, and may be valid. Is this what people want to use the proposed option for, though? Or are they just interested in providing an information service about the advertised prefixes? Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 22:32:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3PL5-0006Pj-1v; Thu, 11 Aug 2005 22:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3PL3-0006Pd-0G for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 22:32:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13517 for ; Thu, 11 Aug 2005 22:32:02 -0400 (EDT) Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3PtS-00015Y-Q2 for ipv6@ietf.org; Thu, 11 Aug 2005 23:07:40 -0400 Received: from S018431 ([68.160.186.73]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IL3002F18DC8822@vms040.mailsrvcs.net> for ipv6@ietf.org; Thu, 11 Aug 2005 21:32:02 -0500 (CDT) Date: Thu, 11 Aug 2005 22:31:56 -0400 From: "timothy enos" In-reply-to: <1123769037.5497.41.camel@localhost.localdomain> To: "'Ralph Droms'" Message-id: <002801c59ee6$03e5ddb0$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Stig Venaas' , greg.daley@eng.monash.edu.au Subject: RE: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Ralph, > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, August 11, 2005 10:04 AM > To: timothy enos > Cc: greg.daley@eng.monash.edu.au; 'Stig Venaas'; ipv6@ietf.org > Subject: RE: Solutions for distributing RFC 3484 address selection > policies > > On Thu, 2005-08-11 at 01:40 -0400, timothy enos wrote: > > [...] > > One thing is that in using DHCPv6, all DHCPv6 clients on the link will > > get the same policy. Also, IMO it wouldn't always be bad for all hosts > > on a link (DHCPv6 or otherwise) to get the same policy. > > It's not the case that all DHCPv6 clients on a link need to be > configured with the same policy; the DHCPv6 server can return a specific > (and potentially different) policy for each client.*** Yes, I see that*** now, thanks. FWIW, I can see potential value for each client on a link having the same RFC 3484 policy. I cannot see the potential value of each (DHCPv6) client having a different policy. > > - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 22:33:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3PMq-0006jO-2E; Thu, 11 Aug 2005 22:33:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3PMn-0006jH-F0 for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 22:33:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13600 for ; Thu, 11 Aug 2005 22:33:51 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3PvD-00017a-8c for ipv6@ietf.org; Thu, 11 Aug 2005 23:09:28 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:3df0:c59f:ffb7:82df]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EC48615218; Fri, 12 Aug 2005 11:33:44 +0900 (JST) Date: Fri, 12 Aug 2005 11:33:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Samita Chakrabarti In-Reply-To: <200508112322.j7BNMIkD239375@jurassic.eng.sun.com> References: <200508112322.j7BNMIkD239375@jurassic.eng.sun.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: erik.nordmark@sun.com, ipv6@ietf.org, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 11 Aug 2005 16:21:02 -0700 (PDT), >>>>> Samita Chakrabarti said: >> First of all, I must say I'm not particularly fascinated by this API. >> As (I think) I said before, I believe this can be useful in very >> limited situations only (especially because applications need to be >> modified - I generally agree with Francis on this point), and most >> applications (and application writers) wouldn't be bothered with using >> the additional feature. In fact, the only people I've ever seen who >> expressed interest in this API are mobile IP(v6) implementors, >> expecting this API can be used in their mobile IP(v6) specific >> implementations (e.g., ones that negotiate with the home agent). I >> respect that the draft provides one section showing usage examples, >> but these are not convincing enough to me. > Yes, this document would be useful for IP mobility aware applications. (Just to make it sure) my point was that "mobility aware applications" were the *only* known example where this API might be useful in practice, even though the API spec is quite general (and that I'm personally not fascinated by this API due to the limited applicability). But again, I won't oppose to publishing this document if others think this API is generally useful. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 11 22:42:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3PUs-0000NT-7A; Thu, 11 Aug 2005 22:42:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3PUq-0000NO-5W for ipv6@megatron.ietf.org; Thu, 11 Aug 2005 22:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13975 for ; Thu, 11 Aug 2005 22:42:09 -0400 (EDT) Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Q3G-0001Mw-4T for ipv6@ietf.org; Thu, 11 Aug 2005 23:17:47 -0400 Received: from S018431 ([68.160.186.73]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IL3002HG8U78422@vms040.mailsrvcs.net> for ipv6@ietf.org; Thu, 11 Aug 2005 21:42:10 -0500 (CDT) Date: Thu, 11 Aug 2005 22:42:04 -0400 From: "timothy enos" In-reply-to: <42FBE9FB.6020005@eng.monash.edu.au> To: , "'Ralph Droms'" Message-id: <002901c59ee7$6e252810$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Stig Venaas' Subject: RE: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Greg, > -----Original Message----- > From: Greg Daley [mailto:greg.daley@eng.monash.edu.au] > Sent: Thursday, August 11, 2005 8:15 PM > To: Ralph Droms > Cc: timothy enos; 'Stig Venaas'; ipv6@ietf.org > Subject: Re: Solutions for distributing RFC 3484 address selection > policies > > Hi Ralph, > > Ralph Droms wrote: > > On Thu, 2005-08-11 at 01:40 -0400, timothy enos wrote: > > > >>[...] > >>One thing is that in using DHCPv6, all DHCPv6 clients on the link will > >>get the same policy. Also, IMO it wouldn't always be bad for all hosts > >>on a link (DHCPv6 or otherwise) to get the same policy. > > > > > > It's not the case that all DHCPv6 clients on a link need to be > > configured with the same policy; the DHCPv6 server can return a specific > > (and potentially different) policy for each client. > > I agree that this is possible, and may be valid. Under what circumstances would this be preferable and/or recommended? That any given configuration is valid (syntactically, and doesn't break any RFC rules) doesn't mean it should be implemented. > > Is this what people want to use the proposed option for, though? > Or are they just interested in providing an information service about > the advertised prefixes? Personally, I'd like to see the policy be more than just an information service about the advertised prefixes. > > Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 01:02:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3RgR-0002OA-2f; Fri, 12 Aug 2005 01:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3RgK-0002NQ-Lg for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 01:02:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18820 for ; Fri, 12 Aug 2005 01:02:11 -0400 (EDT) Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3SEl-0004bl-Ow for ipv6@ietf.org; Fri, 12 Aug 2005 01:37:49 -0400 Received: from S018431 ([68.160.186.73]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IL30021EFBG85E2@vms040.mailsrvcs.net> for ipv6@ietf.org; Fri, 12 Aug 2005 00:02:08 -0500 (CDT) Date: Fri, 12 Aug 2005 01:02:00 -0400 From: "timothy enos" In-reply-to: <1123765600.5497.35.camel@localhost.localdomain> To: "'Ralph Droms'" , "'IETF IPv6 Mailing List'" Message-id: <002d01c59efa$fa5b0990$bcf0fea9@S018431> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Subject: RE: Distribution of RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Ralph, > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ralph Droms > Sent: Thursday, August 11, 2005 9:07 AM > To: IETF IPv6 Mailing List > Subject: Re: Distribution of RFC 3484 address selection policies > > Seems to me the WG ought to work through these questions: > > 1. Is RFC 3484 adequate to solve the address selection problem? > > My guess is "no", because of its references to site-local addresses and > other deficiencies discussed in this thread. If the answer is no, the > first step for the WG would be to update RFC 3484. I for one believe RFC 3484 needs to be updated, largely because of all of the references to site-local unicast addresses. Presuming its deficiencies are deemed significant enough to warrant its updating, it seems we have a case for doing so even before we decide how to distribute it. > > 2. Is there a requirement for automated/administered management of the > address selection policy specified in RFC 3484 (or RFC 3484bis) in > hosts? > > Seems like there is enough interest in this thread for policy management > to warrant WG activity... Agreed. > > 3. What are the right semantics and the right vehicle for providing > management? > > TBD, once we get answers to 1 and 2? > > - Ralph > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 10:50:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ara-0005VY-Pk; Fri, 12 Aug 2005 10:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3arY-0005VT-R9 for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 10:50:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28972 for ; Fri, 12 Aug 2005 10:50:20 -0400 (EDT) Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3bPy-0003Yy-0l for ipv6@ietf.org; Fri, 12 Aug 2005 11:26:04 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B0E955E744; Fri, 12 Aug 2005 16:50:01 +0200 (CEST) Received: from [163.117.203.145] (unknown [163.117.203.145]) by smtp01.uc3m.es (Postfix) with ESMTP id 6B2075E74E; Fri, 12 Aug 2005 16:49:59 +0200 (CEST) In-Reply-To: <42FBE9FB.6020005@eng.monash.edu.au> References: <002501c59e37$30b2a0d0$bcf0fea9@S018431> <1123769037.5497.41.camel@localhost.localdomain> <42FBE9FB.6020005@eng.monash.edu.au> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Fri, 12 Aug 2005 16:50:40 +0200 To: greg.daley@eng.monash.edu.au X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Greg, El 12/08/2005, a las 2:14, Greg Daley escribi=F3: > Is this what people want to use the proposed option for, though? > Or are they just interested in providing an information service about > the advertised prefixes? > I guess that it also would make sense to provide label/preference=20 information about destination prefixes/addresses i.e. not only=20 providing information about the prefixes available in the link, but=20 also about remote prefixes Regards, marcelo > Greg > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 11:15:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bGA-0004NA-UB; Fri, 12 Aug 2005 11:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bG8-0004N2-Oy for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 11:15:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00361 for ; Fri, 12 Aug 2005 11:15:45 -0400 (EDT) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3boZ-0004MI-Jj for ipv6@ietf.org; Fri, 12 Aug 2005 11:51:30 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LRRF7WM0T699RG7Y@vaxh.its.monash.edu.au> for ipv6@ietf.org; Sat, 13 Aug 2005 01:15:24 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EEC67AB545; Sat, 13 Aug 2005 01:15:23 +1000 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id CA2554FB05; Sat, 13 Aug 2005 01:15:23 +1000 (EST) Received: from [211.28.22.62] by mail-store-2.its.monash.edu.au (mshttpd); Sat, 13 Aug 2005 01:15:23 +1000 Date: Sat, 13 Aug 2005 01:15:23 +1000 From: Greg Daley To: marcelo bagnulo braun Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=iso-8859-1 Content-language: en Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: Solutions for distributing RFC 3484 address selection policies X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Marcelo=2C = ----- Original Message ----- From=3A marcelo bagnulo braun =3Cmarcelo=40it=2Euc3m=2Ees=3E Date=3A Saturday=2C August 13=2C 2005 0=3A50 am Subject=3A Re=3A Solutions for distributing RFC 3484 address selection = policies =3E Hi Greg=2C =3E = =3E El 12/08/2005=2C a las 2=3A14=2C Greg Daley escribi=F3=3A =3E =3E Is this what people want to use the proposed option for=2C though= =3F =3E =3E Or are they just interested in providing an information service = =3E about=3E the advertised prefixes=3F =3E =3E =3E = =3E I guess that it also would make sense to provide label/preference = =3E information about destination prefixes/addresses i=2Ee=2E not only = =3E providing information about the prefixes available in the link=2C = =3E but also about remote prefixes I don=27t have a ready-made solution for that one=2C since although there are proposals for route information options in IPv6 ND=2C They only have 6 bits free (in two blocks of 3 bits)=2E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-ietf-ipv6-router-selectio= n- 07=2Etxt I=27d guess in that case=2C only the label would be required=2C since the routing destination already has its own preferences (for routing purposes though=2C not destination address selection=2E=2E=2E) Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 12:31:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cRS-0003FD-O8; Fri, 12 Aug 2005 12:31:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cRP-0003F5-Jt for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 12:31:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04656 for ; Fri, 12 Aug 2005 12:31:28 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3czq-0006kS-MK for ipv6@ietf.org; Fri, 12 Aug 2005 13:07:14 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E3cQo-0007Fy-Eg; Fri, 12 Aug 2005 17:30:54 +0100 Message-ID: <42FCCF0A.4060602@dial.pipex.com> Date: Fri, 12 Aug 2005 17:32:10 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mukesh.k.gupta@nokia.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: margaret wasserman , IPv6 , RFC Editor Subject: draft-ipngwg-icmp-v3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi. In the process of doing some checking on consistency of IANA considerations across the various ICMP updates (while doing the ICMPv6 filtering bcp), I noticed that this draft has two minor IANA related issues: - It should note that it updates RFC2780 as the new IANA considerations replace section 7 of RFC2780 - The IANA considerations section lists type 255 as reserved for extensions but does NOT list type 127 which is also reserved for extensions earlier in the document. Regards, Elwyn -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 12:48:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3chu-0008A8-8p; Fri, 12 Aug 2005 12:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3chq-0008A3-CV for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 12:48:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05341 for ; Fri, 12 Aug 2005 12:48:26 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dGI-0007AO-Ff for ipv6@ietf.org; Fri, 12 Aug 2005 13:24:12 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E3chh-0007pM-H0; Fri, 12 Aug 2005 17:48:21 +0100 Message-ID: <42FCD321.9000303@dial.pipex.com> Date: Fri, 12 Aug 2005 17:49:37 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: narten@raleigh.ibm.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: IANA considerations in rfc2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi. Having done a consistency check across all the ICMP updates, I believe that the IANA considerations of this draft need an overhaul. In particular: - the master policies for types are (or will be) defined in the RFC that comes from draft-ipngwg-icmp-v3 instead of RFC2780. - this document needs to define/continue the registry and explicitly define the policy for the Neighbour Discovery options (since this hasn't previously been properly defined). - it should probably explicitly define the ICMP types and ND options which are being continued from RFC2461 as they don't have an explicit registration in RFC2461. Regards, Elwyn -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 13:05:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cye-0004OF-FQ; Fri, 12 Aug 2005 13:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cyc-0004O7-L1 for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 13:05:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05961 for ; Fri, 12 Aug 2005 13:05:47 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dXA-0007aJ-An for ipv6@ietf.org; Fri, 12 Aug 2005 13:41:33 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 13:05:35 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Aug 2005 13:05:35 -0400 Message-ID: Thread-Topic: IANA considerations in rfc2461bis Thread-Index: AcWfXhyviAzjmgTRR5+pgzc/iFi3DAAAaxSg From: "Soliman, Hesham" To: "Elwyn Davies" , X-OriginalArrivalTime: 12 Aug 2005 17:05:35.0962 (UTC) FILETIME=[0E8B63A0:01C59F60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: IANA considerations in rfc2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org All done, except: > define the policy for the Neighbour Discovery options (since=20 > this hasn't=20 > previously been properly defined). =3D> Did you mean the policy of allocating new option numbers? > - it should probably explicitly define the ICMP types and ND options=20 > which are being continued from RFC2461 as they don't have an=20 > explicit=20 > registration in RFC2461. =3D> I'm not sure I understand what you mean here. What do you mean by "don't have an explicit registration in RFC2461."? Hesham >=20 > Regards, > Elwyn >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 13:17:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dAL-0007tZ-Jg; Fri, 12 Aug 2005 13:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dAJ-0007tN-8K for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 13:17:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06462 for ; Fri, 12 Aug 2005 13:17:51 -0400 (EDT) Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dil-0007tn-Nv for ipv6@ietf.org; Fri, 12 Aug 2005 13:53:38 -0400 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E3dAA-0000He-V1; Fri, 12 Aug 2005 18:17:47 +0100 Message-ID: <42FCDA04.4050504@dial.pipex.com> Date: Fri, 12 Aug 2005 18:19:00 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: IPv6 Subject: Re: IANA considerations in rfc2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Soliman, Hesham wrote: >All done, except: > > > > define the policy for the Neighbour Discovery options (since > > this hasn't > > previously been properly defined). > >=> Did you mean the policy of allocating new option numbers? > > Yes. I don't think this is covered elsewhere and there was no explicit policy for new allocations of ND options in RFC2461. > > - it should probably explicitly define the ICMP types and ND options > > which are being continued from RFC2461 as they don't have an > > explicit > > registration in RFC2461. > >=> I'm not sure I understand what you mean here. What do you >mean by "don't have an explicit registration in RFC2461."? > > The IANA considerations section in RFC2461 was very skimpy and didn't explicitly say what new ICMPv6 message types were being added or what the set of ND options being defined were. It would be useful to have the list in the update as the set of registrations that are being 'continued'. I assume from your comment above that there is a new version in the offing! Elwyn >Hesham > > > > > Regards, > > Elwyn > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > >=========================================================== >This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. >=========================================================== > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 12 13:27:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dJL-0001hf-NE; Fri, 12 Aug 2005 13:27:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dJJ-0001hX-T6 for ipv6@megatron.ietf.org; Fri, 12 Aug 2005 13:27:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06949 for ; Fri, 12 Aug 2005 13:27:10 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3drs-0008D6-Qb for ipv6@ietf.org; Fri, 12 Aug 2005 14:02:57 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 13:27:04 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Aug 2005 13:27:04 -0400 Message-ID: Thread-Topic: IANA considerations in rfc2461bis Thread-Index: AcWfYcMJQ7+fhlvXSbiH3Qk9PyPgBQAARRww From: "Soliman, Hesham" To: "Elwyn Davies" X-OriginalArrivalTime: 12 Aug 2005 17:27:04.0789 (UTC) FILETIME=[0EBEC850:01C59F63] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: IANA considerations in rfc2461bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org > >=3D> I'm not sure I understand what you mean here. What do you > >mean by "don't have an explicit registration in RFC2461."? > > =20 > > > The IANA considerations section in RFC2461 was very skimpy=20 > and didn't=20 > explicitly say what new ICMPv6 message types were being=20 > added or what=20 > the set of ND options being defined were. It would be=20 > useful to have=20 > the list in the update as the set of registrations that are being=20 > 'continued'. =3D> Is this basically a summary of what's already in the document in several sections?=20 > I assume from your comment above that there is a new version=20 > in the offing! =3D> Yes, just for this comment, so I want to make sure I understand exactly what we're required to do.=20 thx, Hesham >=20 > Elwyn >=20 > >Hesham > > > > >=20 > > > Regards, > > > Elwyn > > >=20 > > >=20 > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests:=20 > https://www1.ietf.org/mailman/listinfo/ipv6 > > >=20 > -------------------------------------------------------------------- > > >=20 > > > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >This email may contain confidential and privileged material=20 > for the sole use > > of the intended recipient. Any review or distribution by=20 > others is strictly > > prohibited. If you are not the intended recipient please=20 > contact the sender > > and delete all copies. > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > =20 > > >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Aug 14 00:00:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E49gB-0007DZ-0w; Sun, 14 Aug 2005 00:00:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E49g9-0007DU-Es for ipv6@megatron.ietf.org; Sun, 14 Aug 2005 00:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24958 for ; Sun, 14 Aug 2005 00:00:55 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4AEz-0007EK-HE for ipv6@ietf.org; Sun, 14 Aug 2005 00:36:58 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2C096315 for ; Sun, 14 Aug 2005 00:00:37 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 14 Aug 2005 00:00:36 -0400 Message-Id: <20050814040037.2C096315@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 11 | 19.31% | 54805 | greg.daley@eng.monash.edu.au 12.73% | 7 | 13.53% | 38401 | timbeck04@verizon.net 12.73% | 7 | 12.77% | 36244 | stig.venaas@uninett.no 7.27% | 4 | 6.79% | 19261 | a@arifumi.net 5.45% | 3 | 5.90% | 16738 | fred@cisco.com 3.64% | 2 | 7.34% | 20823 | jinmei@isl.rdc.toshiba.co.jp 5.45% | 3 | 5.18% | 14703 | tjc@ecs.soton.ac.uk 5.45% | 3 | 5.10% | 14469 | rdroms@cisco.com 5.45% | 3 | 3.94% | 11173 | elwynd@dial.pipex.com 3.64% | 2 | 3.43% | 9740 | h.soliman@flarion.com 3.64% | 2 | 3.40% | 9643 | mkt@ecs.soton.ac.uk 3.64% | 2 | 3.17% | 9000 | francis.dupont@enst-bretagne.fr 1.82% | 1 | 2.64% | 7505 | volz@cisco.com 1.82% | 1 | 1.96% | 5576 | sra+ipng@hactrn.net 1.82% | 1 | 1.51% | 4274 | samita.chakrabarti@eng.sun.com 1.82% | 1 | 1.37% | 3892 | john.loughney@nokia.com 1.82% | 1 | 1.37% | 3887 | iesg-secretary@ietf.org 1.82% | 1 | 1.31% | 3724 | marcelo@it.uc3m.es --------+------+--------+----------+------------------------ 100.00% | 55 |100.00% | 283858 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 19 09:28:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66ut-0004q2-GI; Fri, 19 Aug 2005 09:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66ur-0004pw-Nk for ipv6@megatron.ietf.org; Fri, 19 Aug 2005 09:28:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02632 for ; Fri, 19 Aug 2005 09:28:11 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E67Uo-0000qn-9e for ipv6@ietf.org; Fri, 19 Aug 2005 10:05:23 -0400 Received: from ([128.244.96.229]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.15337766; Fri, 19 Aug 2005 09:27:27 -0400 Mime-Version: 1.0 (Apple Message framework v622) To: IPv6 WG Message-Id: <7e9020e808854b5248e34bc52797c815@innovationslab.net> From: Brian Haberman Date: Fri, 19 Aug 2005 09:27:27 -0400 X-Mailer: Apple Mail (2.622) X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SenderID:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 90fbdaf3c139ce803b358d56775b59ed Subject: IETF 63 IPv6 WG Minutes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1335724018==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1335724018== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-121959236; protocol="application/pkcs7-signature" --Apple-Mail-5-121959236 Content-Type: multipart/mixed; boundary=Apple-Mail-4-121959055 --Apple-Mail-4-121959055 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, Attached are the minutes taken for the IPv6 WG meeting in Paris. Please review and comment. Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-4-121959055 Content-Type: text/plain; x-mac-type=42494E41; x-unix-mode=0644; x-mac-creator=74747874; name="IETF63-IPv6-Minutes.txt" Content-Disposition: attachment; filename=IETF63-IPv6-Minutes.txt Content-Transfer-Encoding: 7bit Internet Protocol Version 6 WG (IPv6) Tuesday, August 2 at 1400-1600 CHAIRS: Bob Hinden Brian Haberman ------------------------------------------------------------------ 1. Document Status (Haberman) Status on website: www.innovationslab.net/~brian/IETF63/IPv6/IPv6DocumentStatus.html ------------------------------------------------------------------ 2. Call for Implementation Reports (Haberman) Chairs request submissions of implementation reports for - Privacy Extensions for Stateless Address Autoconfiguration in IPv6 - IPv6 over PPP Implementation reports needed before specifications can be advanced to Draft Standard. RFC2472 update reports should include IPv6CP, Interface ID negotiation, and stateless autoconfig (over PPP). RFC3041 to DS reports should include lifetime management and DAD on temporary addresses. Chairs will send out report templates to mailing list. ------------------------------------------------------------------ 3. IPv6 Node Information Queries (Haberman) Goal: Close open issues draft-ietf-ipngwg-icmp-name-lookups-12.txt Node Information Queries: completed WG last call, some comments received. Intended to document what has been implemented, put as Experimental . Current use does not conform to RFC3307 regarding multicast prefix The other open issue is restricting answering of queries to All-Hosts or All-Routers addresses Pekka Savola: restricting queries is important if the hosts answer pings to those addresses. Comment the issue wasn't specific to this ICMPv6 message. Asked if anyone disagreed with changing the prefix to conform to RFC3307? Means existing implementations have to change and impact on current deployment. Haberman: people asking for the change are switch vendors who want to see it as local use multicast address Bob Hinden: prefer keeping it as is since fairly widely deployed Elwyn Davies: originally agreed with Bob, but can hit cases where nodes respond who weren't addressed ... interference with other multicast groups Jinmei: as an implementor, doesn't mind changing Poll to change Multicast address. About equal. Chairs will take issue to the mailing list. ------------------------------------------------------------------ 4. IPv6 Address Allocation to End Sites (Narten) Goal: Discussion draft-narten-ipv6-3177bis-48boundary-00.txt /64 is a fairly hard boundary. Some RIRs want to allocate /56 rather than /48s. Consensus to make this a working group document. There is no consensus that this will be approved. Brian Carpenter says IAB should be told that this WG is thinking about changing an IAB document. Some would rather they didn't know. Wide ranging discussion on the political aspects of the RIR boundaries, /64 boundaries, and the intentions behind changing the boundaries. Reviewed history. Today, sense that it is time to revisit/revise current policies based on experience gained since 1998 The /64 boundary is architectural. Very costly to change, but space to left of 64 is policy managed. The /48 is a policy boundary. Current RIR IPv6 policy: HD ratio of .8 used measures utilization, /48 to end sites, RIRs making large (/19) allocations to ISPs. How much space do we really have? Should plan for space for 100 years? In 2050, /48 per person means 1/128 of space used. Is this too much? Changing from liberal rules to conservative rules later has downsides, like we did in IPv4. ARIN proposed raising HD ratio to .94 . May see a proposal to change /48 to /56 for SOHO at Oct 26 ARIN meeting. Other RIRs also discussing RFC3177 recommendations - A6 no longer in favor, GSE hooks superceded by multi6/shim6 RIRs view 3177 as IETF position on /48, would welcome IETF comment that /56 causes no architectural issues ipv6-addr-arch-v4 states no boundaries other than 64 bit IID. Discussions about whether to go to /56 is in RIRs not in IETF Document needs to document all relevant technical issues with /56 vs /48 Alain Durand: did the WG make the wrong decision about /64 boundary? Should make sure future specs don't hard code 64 assumption. Thomas Narten: for things like CGA, more bits has technical value. Tony Hain: original policy was based on measuring hosts, whereas it should be networks so good to revisit. Thomas Narten: easiest is to just change HD ratio. Discussion is on possibly doing /56 or not. Changing /64 is off the table. Tony Hain: Need to make sure 3177bis makes it clear that /64 to home is bad. Ralph Droms: what is impact of HD ratio change on operators? does renumbering solve the problem? Geoff Huston: .94 matches what we think is reasonable engineering ratio. Jim Bound: should accept as WG item Jonne Soinenen: it's not just IETF docs that reference /64 but other communities like 3GPP, so it's very much fixed. Ron Desorta: there's a consortium of RIRs which has a mailing list for this purpose, so that's the one place for the discussion (not 5-6) Keith Moore: thinks it's a bad idea to change /48 recommendation. There are places that embed a /48 assumption, like 6to4. Thomas Narten: then the doc should talk about them. Keith Moore: disagrees that the doc should say the policy warrants revisiting. Thomas Narten: doc does not recommend a change. It's just to document the issues. Poll taken to see if there is a consensus to adopt as a working group document. There was a consensus is to adopt. Brian Carpenter: would be good for current IAB to comment, since RFC3177 is an IAB document. ------------------------------------------------------------------ 5. URI Syntax (Fenner) Goal: Make decision to adopt proposal draft-fenner-literal-zone-01.txt Summarized the issues relating to how to represent scope in literal IPv6 addresses in URIs. It's different from the site local issue since there's a specific grammar that makes it explicit there's a scope id Doesn't want to use _ (underline) but not %. Still need to choose replacement for _ Want to either move forward with this type of syntax with limited utility or else abandon the work. Greg Daley: might this be compatible with non URL use? Bill Fenner: possible future path to accept this format outside URLs but not currently Brian Haberman: Supports working on this, not worth effort to change the other spec. Keith Moore: should never use in production use in real applications, but fine with the doc. Should have a statement saying use only for testing. Bill Fenner: willing to accept document as working group item. No objections. Document adopted. ------------------------------------------------------------------ 6. M and O Flags of IPv6 Router Advertisement (Park) Goal: Resolve open issues with draft draft-ietf-ipv6-ra-mo-flags-01.txt Draft defines host configuration behavior is for RFC3315 (DHCPv6) and information configuration behavior is for RFC3736 (stateless DHCPv6) Requirements: 1) Ability to indicate to host that DHCP is not available. 2) Ability to get all DHCP config with a single message exchange. 3) Ability to do DHCP without having to configure routers. Hesham Soliman and Dave Thaler: why is the third one a requirement? Ted Lemon: get rid of acronyms HCB and ICB. Ralph Droms: should not use RFC numbers since they're overloaded. Ted Lemon: what if a rogue router sends RAs to deny service. Greg Daley: covered by the SEND RFC Jinmei Tatyua: not recommending requirements just listing what have heard so far. It's there to get around misconfigured routers. Hesham Soliman: tries to be too intelligent, everything else is configured in the router anyway (prefix etc) Brian Haberman: only situation we need to handle here is just if no prefix option. Bob Hinden: thinks only the first one is actually a requirement. Second one is an internal DHCP issue. Jim Bound: not a lot of DHCPv6 clients out there, so not super painful to change something. But lots of implementations of M and O so hard to mess with. Iljitsch: are there any implementations that do something different with M or O? Discussion will be continued on mailing list. ------------------------------------------------------------------ 7. IPv6 over IEEE802.16 (Kim) Goal: New draft, Initial Discussion draft-jin-ipv6-over-ieee802.16-00.txt Service expected to be active within 1-2 years. WMAN technology, uses standard IEEE MAC address. Transmission doesn't use MAC addresses, just 16 bit connection id since resources are scarce. L2 signaling protocol allocates CIDs to MAC pairs by a base station. Request folks to read draft and comment. Not yet asking to become a WG doc, currently an individual document. Authors encouraged to continue work and refine content and applicability. ------------------------------------------------------------------ 8. Network discovery and spoofing detection (Pashby) Goal: Introduction to drafts Presentation outlines several deployment issues with IPv6 in U.S. Navy test networks. Drafts outline problems and puts forth straw man proposal for addressing. Meant more to kick start discussion of the issues. Proposed list of changes to ND Send NAs to solicited node mcast addr, discard others, same for redirects. Christian Huitema: why not just do SEND instead? Francis Dupont: do we need a huge change just to address spoofing? Jim Bound: some countries are not comfortable with CGAs until IPR issues resolved Erik Nordmark: how does Ron's proposed change help? Brian Haberman: IDS's could detect spoofing since they can get the packets too. Erik Nordmark: could just changing the multicast MAC address then. Purpose is to discover all IPv6 addresses on a network. Propose echo requests to a multicast address responded to after random wait. Encourage people to read docs and comment on list. Chairs request discussion of the issues on the mailing list. ------------------------------------------------------------------ 9. Distributing Default Address Selection Policy using DHCPv6 (Fujisaki) Goal: Discussion draft-fujisaki-dhc-addr-select-opt-00.txt Proposal for using DHCPv6 to distribute Address selection policy. Issues raised with the validity of using DHCPv6 to do the work. Multi-homing and interface vs. node based policy identified as issues. DHCPv6 option for policy table used in RFC 3484 (address selection rules). http://www.nttv6.net/dass/ talks about policy table implementations. Dave Thaler: has problems with multihomed hosts, since this is a global table. Keith Moore: right, plus third parties are often naive and can cause problems. Ralph Droms: is it good to have control over this table is one question, whereas is DHCP the right way to configure is a different question. Ted Lemon: too hard to answer how to deal with multiple interfaces. Tatuya Jinmei: 3484 talks about app control over selection. Little support for this work. ------------------------------------------------------------------ 10. Next Steps for IPv6 w.g. (Hinden) Advancing core specification to Standard Goal: Discussion Since 1994 we have published 61 RFCs! Core protocols went to Draft Standard in 1998. Working group scheduled to close end of this year. Chairs recommend that the core protocols go to Full Standard and already meet the requirements as specified in RFC 2026. Proposed list of core protocols: IPv6, Address Architecture, ICMPv6, Neighbor Discovery, Stateless Autoconfuration , and Path MTU Discovery. Possibly also Privacy Extensions, IPv6 over , and DNS. Chairs propose to not reopen Draft Standard RFCs, just recycle as is. Some of the protocols are in the RFC-editors queue now, IESG could just approve as Full Standard Proposal is similar to NEWTRK proposals to reduce steps in the standards process Margaret Wasserman: in favor of this proposal. Keith Moore: thinks it doesn't qualified as Proposed Standard, since we haven't figured out to handle renumbering, or multiple addresses for a host. Margaret Wasserman: there were no problems when moving to Draft Standard. Keith Moore: recommend we should identify what the missing pieces are. Tony Li: we didn't solve those for IPv4, so should move RFC 791 (IPv4 specification) to Experimental. Ted Lemon: agree. List of RFCs to advance doesn't include APIs since those are Informational Thomas Narten: would like to see fairly substantial deployment and usage. Can we document production deployment or just testing? Greg Daley: we're now seeing same attacks over IPv6 as we do over IPv4, so it's clearly production! Greg Daley: just let queued docs go to Draft without holding them up. Greg Daley question to Keith: is pointing shim6 sufficient? Pekka Savola: Address arch isn't mature enough to advance yet, due to recent changes. Margaret Wasserman: DNS is a draft standard. Wants to move it forward as well. Chairs will put together concrete proposal and send to mailing list. ---------------------------------------------------------------------- --Apple-Mail-4-121959055 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-4-121959055-- --Apple-Mail-5-121959236 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODE5MTMyNzI3WjAjBgkqhkiG9w0B CQQxFgQUHCKpv2U65zR0Y8VAVjARy6oxHqwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEACseMBJ19w3oLuoZBEn2JwAknVIb0DlLb/AoTLyms2Dqv4XK0nWG0LcvYpcvpc+fb8qNU HRYCGlXSvVc4/9jqgbjB9kkiWY7BULJLQI6MPUK3exr5kZAtqcm+KKO+YNtGaoXRF0qrJsKmoHJC ioGE/EbsK1ozTCgaYhIFLAI/jZQRDLJbDGPNAy/r/o+8c3CKMaij5eblyqx/pTCdQ5a2FEH4+vNv 41/jmcHiZqmseTOdkLPDc2YVWS30P/BSdAF6HUp6/SR6m/Vbz6cBxcrMaUr6iFrbDzhywkZxMIDR llp7bZXs61lnlNEeFp1hntbbcbrpxNEYa03qNDGK6dDerwAAAAAAAA== --Apple-Mail-5-121959236-- --===============1335724018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1335724018==-- From ipv6-bounces@ietf.org Sun Aug 21 00:00:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6h0k-0000F0-16; Sun, 21 Aug 2005 00:00:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6h0h-0000Eu-Nk for ipv6@megatron.ietf.org; Sun, 21 Aug 2005 00:00:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22278 for ; Sun, 21 Aug 2005 00:00:37 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6haw-0006Fa-Hr for ipv6@ietf.org; Sun, 21 Aug 2005 00:38:09 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 257403B3 for ; Sun, 21 Aug 2005 00:00:17 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 21 Aug 2005 00:00:17 -0400 Message-Id: <20050821040017.257403B3@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 1 | 80.85% | 21973 | brian@innovationslab.net 33.33% | 1 | 14.94% | 4059 | sra+ipng@hactrn.net 33.33% | 1 | 4.21% | 1144 | jspence@native6.com --------+------+--------+----------+------------------------ 100.00% | 3 |100.00% | 27176 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 22 13:45:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GMc-0001Nd-Az; Mon, 22 Aug 2005 13:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GMZ-0001N0-Rb for ipv6@megatron.ietf.org; Mon, 22 Aug 2005 13:45:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00414 for ; Mon, 22 Aug 2005 13:45:34 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7GxA-0000LB-Ng for ipv6@ietf.org; Mon, 22 Aug 2005 14:23:26 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Aug 2005 13:44:53 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7301996758@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Softwires mailing list Thread-Index: AcWnQTQGJ4oluvT+R1q5oy89F/OwEQ== From: "Durand, Alain" To: , X-OriginalArrivalTime: 22 Aug 2005 17:44:54.0629 (UTC) FILETIME=[348CE950:01C5A741] X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: Softwires mailing list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0102520403==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0102520403== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A741.344B2CB4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A741.344B2CB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a follow-up to the TC bof in Minneapolis and the LRW bof in Paris, we have set-up a mailing list: softwires@ietf.org Hopefully the name will not change, (but we never know... ) once the wg will be ceated by IESG. =20 To subscribe, visit: https://www1.ietf.org/mailman/listinfo/softwires =20 Proposed charter and ML will be posted there shortly. =20 - Alain. ------_=_NextPart_001_01C5A741.344B2CB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As a = follow-up to=20 the TC bof in Minneapolis and the LRW bof in Paris, we have set-up a = mailing=20 list:
softwires@ietf.org
Hopefully the name=20 will not change, (but we never know... ) once the wg will be = ceated by=20 IESG.
 
To = subscribe,=20 visit:
https://www1.ie= tf.org/mailman/listinfo/softwires
 
Proposed charter and=20 ML will be posted there shortly.
 
     -=20 Alain.
------_=_NextPart_001_01C5A741.344B2CB4-- --===============0102520403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0102520403==-- From ipv6-bounces@ietf.org Mon Aug 22 15:09:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HfV-0000a5-1f; Mon, 22 Aug 2005 15:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HfS-0000a0-P5 for ipv6@megatron.ietf.org; Mon, 22 Aug 2005 15:09:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04976 for ; Mon, 22 Aug 2005 15:09:09 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7IG2-0002kC-6l for ipv6@ietf.org; Mon, 22 Aug 2005 15:47:01 -0400 Received: from ([128.244.124.54]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.15456389; Mon, 22 Aug 2005 15:08:20 -0400 Mime-Version: 1.0 (Apple Message framework v622) To: IPv6 WG Message-Id: From: Brian Haberman Date: Mon, 22 Aug 2005 15:08:21 -0400 X-Mailer: Apple Mail (2.622) X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SenderID:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: IETF 63 IPv6 WG Meeting Data X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1277556148==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1277556148== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-401613632; protocol="application/pkcs7-signature" --Apple-Mail-5-401613632 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, I have uploaded all the presentations that I have received and the minutes from the meeting in Paris. They are available at http://www.innovationslab.net/~brian/IETF63/IPv6/ Regards, Brian --Apple-Mail-5-401613632 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwz21DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwOTAxMTcxOTM4WhcNMDUwOTAxMTcxOTM4WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRogfqvQwSubSspmgfho1w Br2IRBf5DI+pvLyiFcMM7KTRomseAAznLq+OjixIzT08u0opCIB91C2fohXwqf05+NVmd3/IIrOh gQoQeFrwZdRwkmA1p6/+ivWwwyiIBBVjyIx5cdULoGi3Nl0hanW99zEHWMR7cr9YRfkhrYwyrLwF 2dUlanpDcoC+PJfimFv7Sp5Ymut3GMuvc4hrzmUBs3GhZVUbxrknxBb9C0ApLa++79wQtcrzK7Nr HkGl63vTkfCaR2HqPE53GT1NvPSQyRUMbVBmx5xzuHUlQAY/fMDOLv45qFa9Xb8XfP1Xb+chYzHX xPx4pqVTzZUnfi3RAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABHGCDHcruXemZ3lBjGb0E+TXfwILkNu UykBjSlywXfghEVSEO/cZ/0tMjrqIn1GF3GZeKecvx/aIFawl2pSUejjnLUrEE6Ro5AQs5kyZI3b ma3GPa+TMEOeXBr8Wp+HwkMAk+McfRfGNGTDIBwF+8LnQmMCPlvTYEfuUZ93AAxCMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODIyMTkwODIxWjAjBgkqhkiG9w0B CQQxFgQU4VUIEZUCz7aEjhC8hS5IW0JllqgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAsfesIhvbBBMpXogIOB4aTVG+aZm7mVnotc5GFaQaG+eGXd4G2IGN7Ou7IFsGw3DbIRxI M9nq7X61MAOpCDJqOUqWEEEJJ9JIQWflC9x8yoNCnvlJv0PwXyiVkO1i/2TH/frg/qdOWDrtswiW jN0S/hIR5X952f70HRpMVbFu6xrJUT+ozO3+SqfZ8z4rU0yXDG+Nj/y2dVC9Ff9goXF/X0eIkf2d 2TxVtAmolHJLZdm64yXfAxACGkDquJeijszL3C7z3qq9fyF+S4XSdbMa1hmT7s99rwSJYEroZ6je /DptCVmggQ1QdPo+ZeJfRWXvs+yvZrjHxQlvDbGexUXUUgAAAAAAAA== --Apple-Mail-5-401613632-- --===============1277556148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1277556148==-- From ipv6-bounces@ietf.org Mon Aug 22 15:20:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Hq6-0002WC-Ta; Mon, 22 Aug 2005 15:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Hq4-0002UR-Bp for ipv6@megatron.ietf.org; Mon, 22 Aug 2005 15:20:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06079 for ; Mon, 22 Aug 2005 15:20:04 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7IQc-00032N-Ra for ipv6@ietf.org; Mon, 22 Aug 2005 15:57:57 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7MJJqGs006079 for ; Mon, 22 Aug 2005 15:19:52 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7MJJnpD284750 for ; Mon, 22 Aug 2005 15:19:49 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7MJJms1007629 for ; Mon, 22 Aug 2005 15:19:48 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-196-178.mts.ibm.com [9.65.196.178]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7MJJk5b007450; Mon, 22 Aug 2005 15:19:47 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j7MJJier019280; Mon, 22 Aug 2005 15:19:44 -0400 Message-Id: <200508221919.j7MJJier019280@cichlid.raleigh.ibm.com> To: Bob Hinden , Brian Haberman Date: Mon, 22 Aug 2005 15:19:44 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: ipv6@ietf.org Subject: Paris slides: IPv6 Address Allocation to End Sites X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org are available at: http://www.cs.duke.edu/~narten/ietf/ipv6-48boundary.pdf http://www.cs.duke.edu/~narten/ietf/ipv6-48boundary.ppt Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 25 00:15:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8961-0007nK-Go; Thu, 25 Aug 2005 00:12:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E895y-0007nA-GR for ipv6@megatron.ietf.org; Thu, 25 Aug 2005 00:12:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13651 for ; Thu, 25 Aug 2005 00:12:04 -0400 (EDT) Received: from ns.64translator.com ([202.214.123.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E896N-0004UW-AH for ipv6@ietf.org; Thu, 25 Aug 2005 00:12:34 -0400 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id j7P4BeW6029247 for ; Thu, 25 Aug 2005 13:11:40 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (ttb215.64translator.com [10.21.33.215] (may be forged)) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id j7P4BZaA037906 for ; Thu, 25 Aug 2005 13:11:35 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Thu, 25 Aug 2005 13:11:29 +0900 From: Yukiyo Akisada To: ipv6@ietf.org Message-Id: <20050825131129.3f586573.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 1.0.0rc (GTK+ 1.2.10; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: RFC2460: question about next header field X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, all. I have a question about next header handling. RFC2460 says, the node send Parameter Problem Code 1 when the node doesn't support the next header type. 4. IPv6 Extension Headers ------------------------------------------------------------------------ 351 If, as a result of processing a header, a node is required to proceed 352 to the next header but the Next Header value in the current header is 353 unrecognized by the node, it should discard the packet and send an 354 ICMP Parameter Problem message to the source of the packet, with an 355 ICMP Code value of 1 ("unrecognized Next Header type encountered") 356 and the ICMP Pointer field containing the offset of the unrecognized 357 value within the original packet. The same action should be taken if 358 a node encounters a Next Header value of zero in any header other 359 than an IPv6 header. ------------------------------------------------------------------------ If the subsequent payload is empty, what should the node do? IPv6 Header Next Header = Destination Options Header Destination Options Header Next Header = unrecognized Next Header type No Next Header Payload = 0 octets Should the node send Parameter Problem? or just discard it? The text says "a node is required to proceed to the next header", and 0 octets payload doesn't need to be proceeded by the node. It can be read that the node can just ignore the packet. But I still think a node need to send Parameter Problem, because the packet is broken. How should the node do? Thanks, ------------------------------------------------------------------------ Yukiyo Akisada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 25 00:48:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89fc-0002Ug-HN; Thu, 25 Aug 2005 00:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89fa-0002TF-6L for ipv6@megatron.ietf.org; Thu, 25 Aug 2005 00:48:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14867 for ; Thu, 25 Aug 2005 00:48:51 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E89fz-0005Ov-IY for ipv6@ietf.org; Thu, 25 Aug 2005 00:49:22 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 24 Aug 2005 21:50:19 -0700 Message-ID: Thread-Topic: RFC2460: question about next header field Thread-Index: AcWpK3bhZlNWEI2iTVaCa0+RdJmehgAA70WQ From: "Vishwas Manral" To: "Yukiyo Akisada" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: RFC2460: question about next header field X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi, I think the ICMP Parameter Problem with code value of 1, could to be sent in such a case. Thanks, Vishwas -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Yukiyo Akisada Sent: Thursday, August 25, 2005 9:41 AM To: ipv6@ietf.org Subject: RFC2460: question about next header field Hi, all. I have a question about next header handling. RFC2460 says, the node send Parameter Problem Code 1 when the node doesn't support the next header type. 4. IPv6 Extension Headers =20 ------------------------------------------------------------------------ 351 If, as a result of processing a header, a node is required to proceed 352 to the next header but the Next Header value in the current header is 353 unrecognized by the node, it should discard the packet and send an 354 ICMP Parameter Problem message to the source of the packet, with an 355 ICMP Code value of 1 ("unrecognized Next Header type encountered") 356 and the ICMP Pointer field containing the offset of the unrecognized 357 value within the original packet. The same action should be taken if 358 a node encounters a Next Header value of zero in any header other 359 than an IPv6 header. =20 ------------------------------------------------------------------------ If the subsequent payload is empty, what should the node do? IPv6 Header Next Header =3D Destination Options Header Destination Options Header Next Header =3D unrecognized Next Header type No Next Header Payload =3D 0 octets Should the node send Parameter Problem? or just discard it? The text says "a node is required to proceed to the next header", and 0 octets payload doesn't need to be proceeded by the node. It can be read that the node can just ignore the packet. But I still think a node need to send Parameter Problem, because the packet is broken. How should the node do? Thanks, ------------------------------------------------------------------------ Yukiyo Akisada -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 25 01:00:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89qZ-000698-FS; Thu, 25 Aug 2005 01:00:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E89qV-00066d-QV for ipv6@megatron.ietf.org; Thu, 25 Aug 2005 01:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15274 for ; Thu, 25 Aug 2005 01:00:11 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E89qx-0005he-5s for ipv6@ietf.org; Thu, 25 Aug 2005 01:00:40 -0400 Received: from impact.jinmei.org (unknown [2001:200:0:8002:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 53BDE1521D; Thu, 25 Aug 2005 13:59:48 +0900 (JST) Date: Thu, 25 Aug 2005 13:59:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> References: <24f4f26fcdc2bfa80e68fd08336e357a@innovationslab.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IPv6 WG Subject: Re: Call for RFC 3041 Implementation Reports X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Wed, 3 Aug 2005 05:20:25 -0400, >>>>> Brian Haberman said: > As mentioned during the IPv6 WG meeting, the chairs are soliciting > implementation reports for IPv6 Privacy Addresses in support of moving > the spec > to Draft Standard. The following template should be used for submitting > these implementation reports. The reports can be sent to the chairs > and/or > the mailing list. (snip) > 6. Tested Interoperability by Feature: > A. Lifetime Management (Section 3.4) > B. DAD Operation (Section 3.2) I'm not sure what "interoperability" should be reported about those...as far as I understand, these are only a matter of the host using RFC3041, and I don't see any "interoperability" issue here. Could you clarify the required information? Regarding DAD, which specification should be the base of the report, RFC3041 or draft-ietf-ipv6-privacy-addrs-v2-04.txt? (The behavior on this is very different between these two versions of the spec). In either case, I suspect "Section 3.2" should actually be "Section 3.3" (more specifically, Step 7 of Section 3.3). In fact, neither RFC3041 or privacy-addrs mentions DAD in Section 3.2 as a part of the protocol specification. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 26 19:00:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nB2-0000Ya-83; Fri, 26 Aug 2005 19:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nAy-0000XN-Ke for ipv6@megatron.ietf.org; Fri, 26 Aug 2005 18:59:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29777 for ; Fri, 26 Aug 2005 18:59:53 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8nBl-0002qr-7e for ipv6@ietf.org; Fri, 26 Aug 2005 19:00:47 -0400 Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7QMxqWR027891; Fri, 26 Aug 2005 16:59:52 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5.Beta0+Sun/8.13.5.Beta0) with ESMTP id j7QMxp3p809499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 26 Aug 2005 15:59:52 -0700 (PDT) Message-ID: <430F9EE7.5040901@sun.com> Date: Fri, 26 Aug 2005 15:59:51 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: erik.nordmark@sun.com, ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Jinmei, Thanks for your careful comments on the draft. > So, if possible, I'd like to realize the API's goal without messing > ai_flags further. I admit this would be difficult in the current > interface to getaddrinfo() though. At least I don't have a clear > idea about how to do that. Possible random thoughts at this moment > (while those are not a perfect solution) include: > - reduce the number of additional flags by the '1 flag per rule' > approach (comment #1) > - add another member to the addrinfo structure for additional > (particularly protocol dependent) flags. note that we could do > this without breaking (binary) backward compatibility since > multiple addrinfo structure are combined as a linked list. That is a good idea, but I think we still need to define one flag in order to provide compatibility for unmodified applications (at the binary as well as source level). I'd like you comments on the approach below: We add a field to the struct addrinfo (to the end so that the offsets of the existing fields are not changed, since this would break existing binaries) called ai_preferences. In this ai_preferences we can then put all the preference related flags. We also define a single new AI_ flag, call it AI_PREFERENCES. This flag indicates that the application has initialized the ai_preferences field (either to zero, or set some of the preferences flags). The getaddrinfo() implementation will only look for flags when AI_PREFERENCES is set; this avoids looking in a ai_preferences field that was not initialized by the application (to provide compatibility for old applications, or those that do not wish to express any preferences). This means that struct addrinfo gets larger, but that will not cause any applications to break, since they use freeaddrinfo() to free the returned list of addrinfo structures. > 3. I suspect the necessity of IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE. > Those might actually be even harmful. The API draft says these > correspond to Rule 2 of the source address selection defined in > RFC3484. But the RFC says: > > Rule 2 (prefer appropriate scope) MUST be implemented and given high > priority because it can affect interoperability. In the past there was requests to add flags for the SCOPE, for both source and destinations. I can't say I'm a big fan of these flags. If there is consensus that we don't need them (Hint: those that want *PREFER_*_SCOPE should speak up now), I don't have a problem dropping them. I'll comment on your other points in a separate mail once we can get past the above issues. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Aug 27 17:29:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E98Eu-0007It-NW; Sat, 27 Aug 2005 17:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E98Eq-0007IR-Lq for ipv6@megatron.ietf.org; Sat, 27 Aug 2005 17:29:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00914 for ; Sat, 27 Aug 2005 17:29:17 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E98Fp-0003Fn-C8 for ipv6@ietf.org; Sat, 27 Aug 2005 17:30:22 -0400 Received: from impact.jinmei.org (PPP237.air-4x8x.dti.ne.jp [210.170.213.5]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2113415218; Sun, 28 Aug 2005 06:28:50 +0900 (JST) Date: Sun, 28 Aug 2005 06:28:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark In-Reply-To: <430F9EE7.5040901@sun.com> References: <430F9EE7.5040901@sun.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 3.0 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 26 Aug 2005 15:59:51 -0700, >>>>> Erik Nordmark said: > That is a good idea, but I think we still need to define one flag in > order to provide compatibility for unmodified applications (at the > binary as well as source level). I'd like you comments on the approach > below: > We add a field to the struct addrinfo (to the end so that the offsets of > the existing fields are not changed, since this would break existing > binaries) called ai_preferences. > In this ai_preferences we can then put all the preference related flags. > We also define a single new AI_ flag, call it AI_PREFERENCES. This flag > indicates that the application has initialized the ai_preferences field > (either to zero, or set some of the preferences flags). This looks like a reasonable idea. And I see the need for the new AI_PREFERENCES flag (i.e., the hint structure is built by the application, and the added field passed by an old application can be garbage). One may want to make the new field more generic, rather than the specific purpose of preferences, but I don't have a strong opinion on this. >> 3. I suspect the necessity of IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE. >> Those might actually be even harmful. The API draft says these >> correspond to Rule 2 of the source address selection defined in >> RFC3484. But the RFC says: >> >> Rule 2 (prefer appropriate scope) MUST be implemented and given high >> priority because it can affect interoperability. > In the past there was requests to add flags for the SCOPE, for both > source and destinations. I can't say I'm a big fan of these flags. > If there is consensus that we don't need them (Hint: those that want > *PREFER_*_SCOPE should speak up now), I don't have a problem dropping them. Perhaps I was not clear enough in my previous message, so I repeat my suggestion (or preference) here. I suggest - to remove IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE, and - to keep IPV6_PREFER_DST_{LARGE,SMALL}SCOPE > I'll comment on your other points in a separate mail once we can get > past the above issues. Okay. But I'll be out of town from now for one week, and I'll be inactive on the (possible) follow-up discussion during the period. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Aug 28 00:00:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ELW-0000we-Ek; Sun, 28 Aug 2005 00:00:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ELV-0000wZ-Cx for ipv6@megatron.ietf.org; Sun, 28 Aug 2005 00:00:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13932 for ; Sun, 28 Aug 2005 00:00:34 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9EMY-0003Js-DA for ipv6@ietf.org; Sun, 28 Aug 2005 00:01:43 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 925BA315 for ; Sun, 28 Aug 2005 00:00:16 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 28 Aug 2005 00:00:16 -0400 Message-Id: <20050828040016.925BA315@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.22% | 2 | 21.65% | 9718 | jinmei@isl.rdc.toshiba.co.jp 11.11% | 1 | 16.39% | 7358 | brian@innovationslab.net 11.11% | 1 | 12.87% | 5776 | erik.nordmark@sun.com 11.11% | 1 | 12.83% | 5759 | alain_durand@cable.comcast.com 11.11% | 1 | 10.78% | 4840 | vishwas@sinett.com 11.11% | 1 | 10.56% | 4739 | yukiyo.akisada@jp.yokogawa.com 11.11% | 1 | 7.88% | 3536 | narten@us.ibm.com 11.11% | 1 | 7.06% | 3170 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 9 |100.00% | 44896 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 29 14:18:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oDK-0000nZ-RR; Mon, 29 Aug 2005 14:18:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oDJ-0000nP-5S for ipv6@megatron.ietf.org; Mon, 29 Aug 2005 14:18:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25138 for ; Mon, 29 Aug 2005 14:18:32 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9oEe-0008Nh-7z for ipv6@ietf.org; Mon, 29 Aug 2005 14:19:59 -0400 Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7TIIRHT017616; Mon, 29 Aug 2005 11:18:28 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5.Beta0+Sun/8.13.5.Beta0) with ESMTP id j7TIIPqU463439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Aug 2005 11:18:27 -0700 (PDT) Message-ID: <43135173.7010804@sun.com> Date: Mon, 29 Aug 2005 11:18:27 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya References: <430F9EE7.5040901@sun.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > This looks like a reasonable idea. And I see the need for the new > AI_PREFERENCES flag (i.e., the hint structure is built by the > application, and the added field passed by an old application can be > garbage). >=20 > One may want to make the new field more generic, rather than the > specific purpose of preferences, but I don't have a strong opinion on > this. Yes, we could call the new field ai_extended_flags or something like=20 that (ai_eflags?). Taking your concern about address family specific flags, we could also=20 explicitly label this (ai_ipv6_flags?). I don't know how to decide which way to go on this, since I currently=20 can't imagine what other things might be added to getaddrinfo() over time= =2E Also, if we change it to only define a single AI flag, are you still=20 concerned about having one flag per "feature" (both a PUBLIC and TMP=20 flag for instance)? I've tried to think of ways of avoiding that for getaddrinfo() (it's=20 easy for setsockopt - just require that the applications call getsockopt = to get the system default flags and then modify those and pass them to=20 setsockopt). For getsockopt, in order to allow the system default to=20 evolved over time and not assuming the applications are recompiled, it=20 seems that, in order to have one flag per feature one would need to=20 introduce a new API to get the initial addrinfo features. Something like hints.ai_preferences =3D getaddrinfo_default_preferences(); or getaddrinfo_defaults(&hints); and then the application can do this request TMP instead of PUBLIC: hints.ai_preferences &=3D ~PUBLIC; hints.ai_preferences |=3D TMP; To me this looks messier than having two flags per feature. And with=20 dynamic libraries it will cause an application linked against the "new"=20 world to fail when run on an older system (which doesn't have the new=20 function in libc/libnsl/libsocket/wherever). Comments? >>If there is consensus that we don't need them (Hint: those that want >>*PREFER_*_SCOPE should speak up now), I don't have a problem dropping t= hem. >=20 >=20 > Perhaps I was not clear enough in my previous message, so I repeat my > suggestion (or preference) here. I suggest >=20 > - to remove IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE, and > - to keep IPV6_PREFER_DST_{LARGE,SMALL}SCOPE ok. Patiently waiting for arguments from others to keep=20 IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 29 15:29:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pK8-0001gu-40; Mon, 29 Aug 2005 15:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pK6-0001gp-BP for ipv6@megatron.ietf.org; Mon, 29 Aug 2005 15:29:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01523 for ; Mon, 29 Aug 2005 15:29:36 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9pLS-0002TV-J7 for ipv6@ietf.org; Mon, 29 Aug 2005 15:31:05 -0400 Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7TJTXTW028948; Mon, 29 Aug 2005 13:29:33 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5.Beta0+Sun/8.13.5.Beta0) with ESMTP id j7TJTWqU485044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Aug 2005 12:29:33 -0700 (PDT) Message-ID: <4313621D.7080205@sun.com> Date: Mon, 29 Aug 2005 12:29:33 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Samita.Chakrabarti@eng.sun.com, julien.ietf@laposte.net Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > As requested, here are my comments about the addrselect-api draft. >=20 > First of all, I must say I'm not particularly fascinated by this API. > As (I think) I said before, I believe this can be useful in very > limited situations only (especially because applications need to be > modified - I generally agree with Francis on this point), and most > applications (and application writers) wouldn't be bothered with using > the additional feature. In fact, the only people I've ever seen who > expressed interest in this API are mobile IP(v6) implementors, > expecting this API can be used in their mobile IP(v6) specific > implementations (e.g., ones that negotiate with the home agent). I > respect that the draft provides one section showing usage examples, > but these are not convincing enough to me. FWIW To me, the public/temporary address knob is just as important, if=20 not more important than the home/coa knob. > 3. I suspect the necessity of IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE. > Those might actually be even harmful. The API draft says these > correspond to Rule 2 of the source address selection defined in > RFC3484. But the RFC says: >=20 > Rule 2 (prefer appropriate scope) MUST be implemented and given hi= gh > priority because it can affect interoperability. >=20 > Is it really okay to provide an easy knob for applications to > "reverse" the logic despite the strong requirement? And, I'm > actually not sure in which (practical) case we want to specify the > non default rule. The last paragraph of Section 3 provides an > example, but it's not very specific, and cannot be used as a > practical example. >=20 > At the very least, I'm not even sure how the logic of Rule 2 is > modified if we specify IPV6_PREFER_SRC_SCOPE. The rule defined in > RFC3484 is: >=20 > Rule 2: Prefer appropriate scope. > If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB > and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If > Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. >=20 > How would this look like with IPV6_PREFER_SRC_SCOPE? FWIW the semantics of IPV6_PREFER_SRC_SMALLSCOPE would be to invert rule = 2, so that the algorithm instead of prefering the smallest scoped source = which has a scope of at least the destination address, it would prefer=20 the largest scoped source which has a scope which is at most the same as = the destination address. But, like you, I question the utility of this. > SEMI SUBSTANTIAL COMMENTS >=20 > 4. Considering the background motivation of the advanced API, I think > we should also provide an ancillary-data object corresponding to > the proposed socket option in order to control the address > selection policy per-packet basis with a single system call (i.e., > sendmsg()). We can definitely add that. Although I sometimes wonder how useful ancillary data options are on the = send side (they are critical on the receive side, so that the=20 application can see what was "part of" each received datagram). > 5. (AFAICS) This document does not explicitly define the return value > of getsockopt(IPV6_ADDR_PREFERENCES). Even though it's pretty > trivial, I believe an API specification should generally provide > such 'trivial' things very clearly and explicitly. Do you mean the actual return value (which is 0/-1 according to the Open = Group standard for getsockopt), or what value is returned in the *optval?= > 6. [1st line of page 4 (continued from page 3)] >=20 > [...] Since source address selection and destination address > ordering need to be partially implemented in getaddrinfo() [3] the= > corresponding set of flags are also defined for that routine. >=20 > I think this is too strong. Although destination address ordering > (selection) would typically be implemented through getaddrinfo(), > the selection rules themselves are quite general and could be > realized in some other way. Yes, the point is that the API shouldn't constrain or assume which parts = of address selection is implemented in getaddrinfo() or in the kernel.=20 We'll make this more clear. Something along the lines of "should not assume that implementations=20 implementa particular aspect of RFC 3484 in getaddrinfo" > 7. [3rd paragraph of Section 5] > [...] Thus when > AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and = SA > before SB likewise. >=20 > I don't understand this sentence. What does 'and SA before SB > likewise' mean? Oops. I should say "Then SA is used when communication to DA, thus the temporary address gets preferred." > 8. [page 12 (Section 5), just after the flag list] >=20 > The above flags are ignored for the AF_INET address family as the > address selection algorithm defined in section 5 of [1] only appli= es > to the IPv6 addresses. >=20 > This is not really true. RFC3484's destination address selection > considers both IPv4 and IPv6 addresses (See Section 3.2 of > RFC3484). The statement was try when there was no DST flags. So we can correct it to say "the above SRC flags ... as the source=20 address selection ..." > Besides, even if RFC3484 only considered IPv6 addresses, the API > statement would still not be very accurate: what if we have > IPv9?:-) Currently the document is silent on AF_INET9 semantics; did you want it=20 to say something specific about it? ;-) > 9. [first paragraph of Section 6] >=20 > An application only needs to call getsockopt() prior calling > setsockopt() if the application needs to be able to restore the > socket back to the system default preferences. >=20 > This seems odd. Shouldn't the application just be able to reset > the rules to the default by specifying the all-0 flags? If not, > why do we need the sets of two flags to begin with? We need two flags per feature in order handle getaddrinfo() without=20 casting the default flags in concrete and not introducing some new getaddrinfo_default_preferences() function. To me it makes sense to have setsockopt work the same way conceptually=20 as getaddrinfo, so as long as getaddrinfo has two flags per feature,=20 then setsockopt should have the same. With two flags then for any X/not-X pair, the semantics of setting=20 neither X or not-X is a no-op. This implies that setting no flag at all must also be a no-op. > 10. [second code fragment shown in Section 6] >=20 > This does not seem to be very accuratete or consistent. According > to manual pages (available around me), the third arguments of > getsockopt() and setsockopt() are 'void *' and 'const void *', > respectively. On the other hand, this example code casts the > arguments to setsockopt() as 'char *' while it simply passes > 'uint32_t *' to getaddrinfo(). If we ignore minor type-matching > issues for brevity, I'd simply remove all the cast. If we're > willing to show casting for accuracy, we should be consistent and > use accurate casting for all the examples. Will fix. > 11. [second to last paragraph of Section 6] >=20 > In order to allow different implementations to do different parts = of > address selection in getaddrinfo() and in the protocol stack, this= > specification requires that applications set the same flags when > calling getaddrinfo() and when calling setsockopt(). For example,= if > the application sets IPV6_PREFER_SRC_COA flag, it must use > AI_PREFER_SRC_COA flag when calling getaddrinfo(). If application= s > are not setting the same flags the behavior of the implementation = is > undefined. >=20 > The phrase of "the same flags" (there are two occurrences) is not > very accurate, since these are actually different, at least as macro > names. Correct. The same flag at the semantic level, which correspond to different flags = for the two API parts. But if we do a ai_preferences type field, then we can actually use the=20 same flag constants in both places (IPV6_PREFER_...) if we want to. This = would make the document shorter, and might be a simplication for the user= s. > 12. [second bullet of Section 7] >=20 > What would getsockopt() return for preference flags that are not > supported in the system? (see also comment #5) I think it makes sense to return the defaults per RFC 3484 and its=20 future updates. Thus IPV6_PREFER_SRC_PUBLIC would be set even if=20 temporary addresses are not implemented, and IPV6_PREFER_SRC_HOME set=20 even if mobile IPv6 is not implemented. But this is more from a consistency reason than by necessity; returning=20 0 for those flags would be ok as well assuming the application just=20 turns flags on and off. > 13. [third bullet of Section 7] >=20 > If an implementation supports both stream and datagram sockets, i= t > should implement the address preference mechanism API described i= n > this document on types of sockets. >=20 > I simply don't understand what this means...could you elaborate? > (BTW: perhaps 'on types of sockets' should be 'based on types of > sockets'? Even if so, I still don't understand what this means, > though) Oops - should say "on both types of sockets." > 14. [second to last paragraph of Section 8] >=20 > Other destination rules (#4-prefer home address; #7-prefer native > interfaces) could have been applicable. But the problem is that t= he > local system does not know whether a destination address is a tunn= el- > address for destination rule #7. It can only know for sure if the= > destination address is one of its own. >=20 > I don't think this is really correct. First, destination rule #7 is > 'Prefer native transport' not 'interfaces'. Correct. Will fix. > Second, the > implementation can syntacatically identify 'non-native' destinations > in some cases (e.g., for 6to4 addresses).=20 Yes, but we have the preference table to handle that, without any=20 explicit rules on the nativeness of the transport. (It might be a defect in 3484 that it has both the "prefer native=20 transport" and the 6to4 addresses in the table. What happens when they=20 conflict?) > Third, at least in > theory, the local implementation (even an application) could > identify the outgoing interface for a given destination, and might > be able to identify it's a tunneling interface. I do not > necessarily require this API consider destination rule #7, but the > "excuse" for not doing so should be accurate and convincing. Sure, at the local end. But the text in RFC 3484 can be interpreted to mean that by magic the=20 host can determine whether there is some IPv6 in IPv4 tunnel somewhere=20 between the host and a particular destination address. It can only do=20 that if 1) the destination syntactically indicates it does tunneling as=20 in the case of 6to4, or 2) the tunnel starts on the host itself. What do you suggest we clarify to make this more accurate? > 15. [Section 10] > Do we really need (standardize) a separate function like > inet6_is_srcaddr()? Perhaps I'm pretty dubious about this > just because I'm dubious about the usefulness of the entire API in > the first place, but I'd suggest confirming this point with other > implementers, particularly with those who are interested in this > API. I guess the feedback we've gotten doesn't capture whether or not it is=20 necessary; only whether or not it is accurately described. I don't recall anybody else arguing against this function. So I'm=20 interested in the opinion of others. And since you're dubious about the entire API, I guess you could argue=20 we should remove all the other aspects of the API as well ;-) Can't do it a function at a time. > 16. [last paragraph of page 20] > The function returns true when srcaddr corresponds to a valid addr= ess > in the node and that address type satisfies the preference flag(s)= =2E >=20 > I don't think 'that address type satisfies the preference flag' is > well-defined, although it is intuitively understandable. Please be > more precise (c.f. comment #5). There may actually be subtle cases: > e.g., what does it mean if I specify IPV6_PREFER_SRC_SMALLSCOPE as > 'flags'? That is, 'small' is only meaningful when we are comparing > multiple things, while this function takes only one address. I > suspect this indicates we should reconsider the function design. We tried to make it clear which flags can and can not be tested, but I=20 see the text is still not clear on this. The SCOPE aspects can not be=20 tested with inet6_is_srcaddr(), but can be tested with=20 INET6_IS_LINKLOCAL etc. > 17. [regarding inet6_is_srcaddr() in general] >=20 > If we really need this function (see comment #15), I believe we > should clearly separate error cases, i.e., we should not overload > the 'false' return value. This might sound a matter of taste, but I > believe it's a common and well-known practice. OK. There are two different ways to do this and I'd appreciate your opinion=20 on which one to choose. 1. A function which returns 3 values: true, false, failure. E.g int inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, uint32_t flags); with 3 defined constans for the 3 possible return values. A special case is true=3D1, false=3D0, fail=3D-1. 2. A function which returns 0/-1 for ok/fail (like most library calls),=20 and has an extra result parameter for the true/false response. For exampl= e, int inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, uint32_t flags, int *resultp); Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------