From ipv6-bounces@ietf.org Sun May 01 00:00:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS5dN-0001OO-LF; Sun, 01 May 2005 00:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS5dL-0001OD-Gu for ipv6@megatron.ietf.org; Sun, 01 May 2005 00:00:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22726 for ; Sun, 1 May 2005 00:00:40 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DS5qk-00041e-CF for ipv6@ietf.org; Sun, 01 May 2005 00:14:34 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D70621BC for ; Sun, 1 May 2005 00:00:30 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 01 May 2005 00:00:30 -0400 Message-Id: <20050501040030.D70621BC@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) 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 --------+------+--------+----------+------------------------ 14.29% | 7 | 16.39% | 41022 | jinmei@isl.rdc.toshiba.co.jp 16.33% | 8 | 13.63% | 34130 | jinmei@wide.ad.jp 12.24% | 6 | 9.23% | 23118 | rt+ipv6-2462bis@rt.psg.com 6.12% | 3 | 9.92% | 24838 | brian@innovationslab.net 8.16% | 4 | 6.66% | 16668 | jari.arkko@kolumbus.fi 6.12% | 3 | 5.39% | 13482 | ranmails@gmail.com 4.08% | 2 | 5.96% | 14912 | h.soliman@flarion.com 4.08% | 2 | 5.55% | 13906 | rdroms@cisco.com 4.08% | 2 | 4.27% | 10695 | peter.grubmair@siemens.com 4.08% | 2 | 4.17% | 10440 | housley@vigilsec.com 4.08% | 2 | 3.83% | 9583 | christopher_plummer@raytheon.com 4.08% | 2 | 3.38% | 8471 | qing.li@bluecoat.com 2.04% | 1 | 2.46% | 6162 | alh-ietf@tndh.net 2.04% | 1 | 2.22% | 5551 | brc@zurich.ibm.com 2.04% | 1 | 1.95% | 4883 | adrian@olddog.co.uk 2.04% | 1 | 1.74% | 4353 | pekkas@netcore.fi 2.04% | 1 | 1.66% | 4151 | sra+ipng@hactrn.net 2.04% | 1 | 1.59% | 3975 | slblake@petri-meat.com --------+------+--------+----------+------------------------ 100.00% | 49 |100.00% | 250340 | 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 May 02 06:54:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSYZD-0000ZM-Q6; Mon, 02 May 2005 06:54:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSYZB-0000Sh-RT for ipv6@megatron.ietf.org; Mon, 02 May 2005 06:54:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22594 for ; Mon, 2 May 2005 06:04:25 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSY0W-0006Zh-VB for ipv6@ietf.org; Mon, 02 May 2005 06:18:34 -0400 Received: from fenestro.dyndns.org ([24.6.155.213]) by comcast.net (sccrmhc14) with ESMTP id <20050502100414014009o5iae>; Mon, 2 May 2005 10:04:15 +0000 Received: from [192.168.116.133] (localhost [127.0.0.1]) by fenestro.dyndns.org (8.12.9p2/8.12.9) with ESMTP id j42A476U014854 for ; Mon, 2 May 2005 03:04:08 -0700 (PDT) (envelope-from margaret@thingmagic.com) Mime-Version: 1.0 Message-Id: Date: Mon, 2 May 2005 06:04:02 -0400 To: ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: AD Review of draft-ietf-ipv6-optimistic-dad-05.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 All, I have finished my AD review of draft-ietf-ipv6-optimistic-dad-05.txt. I found no blocking issues, and I have sent the document to IETF Last Call. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 02 07:49:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZQB-0006HH-A8; Mon, 02 May 2005 07:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSNyh-0001eJ-SH for ipv6@megatron.ietf.org; Sun, 01 May 2005 19:36:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24609 for ; Sun, 1 May 2005 19:35:56 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSOCG-00056Y-TS for ipv6@ietf.org; Sun, 01 May 2005 19:50:01 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j41NZj806549; Mon, 2 May 2005 02:35:45 +0300 (EET DST) X-Scanned: Mon, 2 May 2005 02:35:33 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j41NZXaa027119; Mon, 2 May 2005 02:35:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Amllox; Mon, 02 May 2005 02:35:31 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j41NZUM29699; Mon, 2 May 2005 02:35:30 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 2 May 2005 02:35:29 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 2 May 2005 02:35:28 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 18:35:14 -0500 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: Sun, 1 May 2005 18:35:13 -0500 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B56C575@daebe102.NOE.Nokia.com> Thread-Topic: Security considerations of the ICMPv6 draft Thread-Index: AcVHgi9qgaX8oqtiSym2zRm+xNju9wHI6ewA To: , X-OriginalArrivalTime: 01 May 2005 23:35:14.0582 (UTC) FILETIME=[6CBD7360:01C54EA6] X-Spam-Score: 0.3 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Security considerations of the ICMPv6 draft 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 Fernando, Sorry for replying late :) After reading this mail, I am convinced that we should put the following text that you proposed in the ICMPv6 draft. =3D=3D=3D ICMP error messages signal network error conditions that=20 were encountered while processing an internet datagram.=20 Depending on the particular scenario, the error conditions=20 being reported might or might not get solved in the near=20 term. Therefore, reaction to ICMP error messages may depend=20 not only on the error type and code, but also on other factors=20 such as the time the error messages are received, previous=20 knowledge of the network error conditions being reported,=20 and knowledge of the network scenario in which the receiving=20 host is operating. =3D=3D=3D I will try to submit the draft after making all the due changes. Regards Mukesh > -----Original Message----- > From: ext Fernando Gont [mailto:fernando@gont.com.ar] > Sent: Friday, April 22, 2005 2:49 PM > To: Gupta Mukesh.K (Nokia-NET/MtView); pekkas@netcore.fi > Cc: ipv6@ietf.org > Subject: RE: Security considerations of the ICMPv6 draft >=20 >=20 > At 13:41 20/04/2005 -0500, Mukesh.K.Gupta@nokia.com wrote: >=20 > > > * I have not read the latsts update of the IPsec specs. Do > > > they know state > > > it clearly that if you're using IPsec, you should drop those > > > ICMP messages > > > that arrive without IPsec authentication? (If not, IPsec=20 > won't help). > > > >The new IPsec Security Architecture document (section 6) discusses > >this and requires the implementation to provide to knob to control > >this. >=20 > Then this reinforces that of "Validating ICMP messages at the=20 > upper layers=20 > is a good thing, anyway", as using IPsec does not imply ICMP=20 > messages will=20 > be handled as expected. > Also, if you want to send packets that are larger than the=20 > IPv6 minimum=20 > MTU, you depend on PMTUD, and thus you cannot apply that=20 > policy of "drop=20 > those ICMP messages that are not authenticated", as that=20 > would be sort of=20 > shooting your own foot. >=20 >=20 > > > If you agree with these changes, the text would look like: > > > =3D=3D=3D > > > 6. As the ICMP messages are passed to the upper-layer > > > processes, it is possible to perform attacks on the > > > upper layer protocols (e.g., TCP) with ICMP [TCP-attack]. > > > It is recommended for the upper layers to perform some > > > form of validation of ICMP messages (using the > > > information contained in the payload of the ICMP message) > > > before acting upon them. The actual validation checks > > > are specific to the upper layers and are out of the scope > > > of this spec. Protecting the upper layer with IPsec > > > mitigates these attacks. > > > =3D=3D=3D > > > >This looks ok to me. >=20 > Great! >=20 >=20 > > > =3D=3D=3D > > > ICMP error messages signal network error conditions that were > > > encountered > > > while processing an internet datagram. Depending on the particular > > > scenario, the error conditions being reported might or might > > > not get solved > > > in the near term. > > > Therefore, reaction to ICMP error messages may depend not > > > only on the error > > > type and code, but also on other factors such as the time=20 > the error > > > messages are received, previous knowledge of the network > > > error conditions > > > being reported, and knowledge of the network scenario in which the > > > receiving host is operating. > > > =3D=3D=3D > > > > > > Note that the text does not say what a transport protocol > > > should do, but rather relaxes the requirements stated in > > > RFC 1122. > > > >I agree that this problem (relaxing/changing the hard/soft errors > >and the actions associated with them) needs to be addressed but > >I am not still sure if ICMPv6 draft is the right place to do it :( >=20 > I think it is. ICMPv6 must define both the syntax and the=20 > semantics of ICMP=20 > messages. Currently, it defines only the syntax. So it=20 > defines the syntax=20 > of error messages, but provides no hints on what these error=20 > mean (should I=20 > assume they will remain in the near term? Should I assume=20 > they will not?=20 > Can I take them as a hint and assume anything?). What is=20 > worse, there's RFC=20 > 1122, which makes statements on ICMPv4. As the ICMPv6 spec=20 > does not cover=20 > those issues (hard and soft errors), most implementers will=20 > just try to=20 > extrapolate RFC 1122 to ICMPv6. >=20 >=20 > >ICMP is just providing the messages to convey the error conditions. > >As it is RFC 1122 (Requirements for internet hosts) and NOT the ICMP > >RFC, which is describing the soft/hard errors and their associated > >action, shouldn't it be the update to RFC 1122 or TCP or something > >else that updates that text? >=20 > I don't think so. RFC 1122's statements on this issue are=20 > just filling=20 > holes in the ICMP and the TCP specifications. Basically, RFC=20 > 792 defined=20 > only the syntax of ICMP messages, but did not define their=20 > semantics. So=20 > the upper layers did not have any hints on what to do with them. > RFC 1122 then said "these ICMP error types/codes indicate hard error=20 > conditions; these other ones indicate soft error conditions",=20 > thus filling=20 > the hole in the ICMP spec. Having defined the semantics of=20 > ICMP messages,=20 > RFC 1122 then fills the hole in the TCP spec, stating "as=20 > these ICMP error=20 > types/codes indicate hard errors, TCP should abort the=20 > connection; as these=20 > other ones indicate soft errors, TCP should not abort the=20 > corresponding=20 > connection". >=20 > So my point is that ICMPv6 should define the semantics of the=20 > messages for=20 > which it defines their syntax. Then upper layer protocols=20 > could then decide=20 > what to do with them. >=20 > Actually, the text I proposed does not get too much into defining the=20 > semantics. Just tries to relax RFC 1122 to mean that "soft=20 > errors" and=20 > "hard errors" are not a "black or white" thing, thus making=20 > it possible for=20 > upper layer protocols to do what they think is best. >=20 > Two examples that show how this subtle text would be important: >=20 > * You may be aware of draft-gont-tcpm-icmp-attacks. It=20 > describes a number=20 > of attacks that can be performed against TCP and other=20 > similar protocols.=20 > One of the attacks is a blind connection-reset attack that=20 > can be performed=20 > by means of the so-called ICMP "hard error" messages. As a=20 > counter-measure=20 > against this attack, my draft proposes to make TCP treat=20 > "hard errors" as=20 > "soft errors" if they are received for connections that are=20 > in any of the=20 > synchronized states. The arguments against this proposal have=20 > so far been=20 > that we would be changing not only TCP's reaction to these=20 > errors, bu also=20 > the semantics of ICMP messages themselves. > Making the mod (actually, "addition") I proposed would allow TCP to=20 > implement this modification, without violating any existing=20 > spec. As a=20 > result, TCP over IPv6 wouldn't be vulnerable to this attack.=20 > Given the=20 > number of products of different vendors that were found=20 > vulnerable when=20 > NISCC released their vulnerability advisory, I think it would=20 > be a good=20 > thing for ICMPv6 to take action on this issue. >=20 > * You may be aware of my draft draft-gont-tcpm-tcp-soft=20 > errors, that was=20 > triggered by draft-ietf-v6ops-v6onbydefault. Basically, we=20 > wanted to avoid=20 > long delays between connection-establishment attempts by=20 > making TCP abort=20 > connections upon receipt of an ICMP error message while in any of the=20 > non-synchronized states (i.e., when the connection wasn't yet=20 > ESTABLISHED).=20 > The arguments against this proposal were, basically, that RFC=20 > 1122 stated=20 > that TCP should not abort a connection upon receipt of a=20 > so-called ICMP=20 > "soft error", and that as soft errors would likely be solved=20 > in the near=20 > term, the proposed behaviour was a bad idea. > Defining the semantics in ICMPv6 (or, as I'm proposing, at=20 > least relaxing=20 > those in RFC 1122) would have let somoother progress of this=20 > proposal. At=20 > least for IPv6, there wouldn't be arguments for not adopting=20 > it. Not the=20 > same, at least. >=20 > Kindest regards, >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org >=20 >=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 Mon May 02 14:16:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfT4-0001rj-LF; Mon, 02 May 2005 14:16:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfT0-0001l7-6I; Mon, 02 May 2005 14:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11338; Mon, 2 May 2005 14:16:25 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSfgj-00019s-Jt; Mon, 02 May 2005 14:30:37 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DSfSz-0006rZ-Bt; Mon, 02 May 2005 14:16:25 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 02 May 2005 14:16:25 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Last Call: 'Optimistic Duplicate Address Detection for IPv6' to Proposed Standard X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org 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 received a request from the IP Version 6 Working Group to consider the following document: - 'Optimistic Duplicate Address Detection for IPv6 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-05.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 02 15:52:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgyF-0006zk-Pg; Mon, 02 May 2005 15:52:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgyB-0006z7-4i; Mon, 02 May 2005 15:52:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26962; Mon, 2 May 2005 15:52:41 -0400 (EDT) Message-Id: <200505021952.PAA26962@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 02 May 2005 15:52:41 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-03.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-addr-arch-v4-03.txt Pages : 26 Date : 2005-5-2 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-3513 "IP Version 6 Addressing Architecture". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-addr-arch-v4-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-2155000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-addr-arch-v4-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-2155000.I-D@ietf.org> --OtherAccess-- --NextPart 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 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon May 02 23:29:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSo6Q-0000nu-Ix; Mon, 02 May 2005 23:29:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSo6L-0000nH-Lt; Mon, 02 May 2005 23:29:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19685; Mon, 2 May 2005 23:29:35 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSoK6-0001ui-4P; Mon, 02 May 2005 23:43:53 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IFW001VF9OYJC@mailout2.samsung.com>; Tue, 03 May 2005 12:29:23 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IFW002MR9OYVM@mmp1.samsung.com>; Tue, 03 May 2005 12:29:22 +0900 (KST) Date: Tue, 03 May 2005 12:29:10 +0900 From: "Soohong Daniel Park@SAMSUNG.COM" In-reply-to: To: =?ks_c_5601-1987?B?J0pJTk1FSSBUYXR1eWEgLyA/lr6SQo3GJw==?= , "'Pekka Savola'" Message-id: <000701c54f90$4533e140$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org, 'IPv6 WG' Subject: [Resolving Issues]IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 all I've tried to note down several considerable points. Let me know your view on them if I am missing anything. If acceptable, I will make a revision once more. ============================================ + means Concern - means Considerable mentions from ML $ means trial efforts on resolving them [Issue 1] "Client operation which is set to M-Policy 1 along with 3736 DHCPv6 server" + if a full DHCPv6 client is initiated and server is only 3736, the client get back the Information Configuration Behaviour ? or sending the Solicit to server forever ? - Just indicating that it's host/network admin misconfiguration - Fall-back behaviour to Information Configuration Behaviour (see Issue 2) - Updating original DHCPv6 specifications (3315, 3736) $ Trial: just saying this issue as an admin misconfiguration including Trial text of Issue 2. [Issue 2] "Parallel operation of HCB and ICB with DHCPv6 specification" RFC3315 does not preclude a client from initiating an Information-request /Reply message exchange in parallel with or subsequent to a Solicit /Advertise/Request/Reply message exchange + Breaking the sense of RFC2462 (Section 5.5.3) - Remaining it as a general issue and simple mention in this document $ Trial: if a client does not receive any response from DHCPv6 server while performing Host Configuration Behaviour, the client then begins Information Configuration Behaviour in parallel with Host Configuration Behaviour. It causes a considerable case as non-addresses configuration since Information Configuration Behaviour does not include addresses information. The authors remain this issue to be resolved in the related working group (probably DHC WG). [Issue 3] "Inconsistent M and O flags of RA" + Inconsistent RA is a in-scope problem of this document ? - More describing of why M/O transitions are a bigger problem than other inconsistent information $Trial: In the end, it is administrator's responsibility to ensure the consistency among Router Advertisement parameters from multiple routers in the same single link as described in Section 5.6 of [RFC2462]. The authors thus remain "Handling of M and O flags from multiple routers" out of scope of this document. [Issue 4] "Default policy on M/O flags" HCB using RFC3315 - M-Policy 2, otherwise M-Policy 3 (HCB is not implemented) ICB using RFC3736 - O-Policy 1 or 2 + Is it fully acceptable ? $Trial: If not acceptable, please make more comments. ! [Editorial] + In the last sentence of Section 12 - s/is different form/is different from/ $Trial: done + SEND is now published as an RFC (RFC3971) $Trial: done + if we need an update version of this document (I believe we do), - we'll need to use the new IPR boilerplate (e.g., with version 1.29 of xml2rfc) $Trial: will be done by next version ============================================ Thanks. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, 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 May 03 06:31:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSugx-0003Hh-8x; Tue, 03 May 2005 06:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSugv-0003Dt-5g; Tue, 03 May 2005 06:31:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27857; Tue, 3 May 2005 06:31:46 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuum-0004eQ-NH; Tue, 03 May 2005 06:46:09 -0400 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j43AVcJl158824; Tue, 3 May 2005 10:31:38 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j43AVc5p249922; Tue, 3 May 2005 12:31:38 +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 j43AVcsT015824; Tue, 3 May 2005 12:31:38 +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 j43AVc6U015815; Tue, 3 May 2005 12:31:38 +0200 Received: from zurich.ibm.com (sig-9-145-129-244.de.ibm.com [9.145.129.244]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA92776; Tue, 3 May 2005 12:31:37 +0200 Message-ID: <4277530A.3070901@zurich.ibm.com> Date: Tue, 03 May 2005 12:31:38 +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: Adrian Farrel References: <9C422444DE99BC46B3AD3C6EAFC9711B087EE13D@tayexc13.americas.cpqcorp.net> <04fc01c54bf9$f7083fa0$1c849ed9@Puppy> In-Reply-To: <04fc01c54bf9$f7083fa0$1c849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, rtgwg@ietf.org Subject: Re: 6LSA IETF Drafts 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 Adrian, There is one important difference, which is that the M in MPLS stands for multiprotocol. A label switched architecture for one particular network layer protocol is not the same as a multiprotocol architecture. Brian Adrian Farrel wrote: > Jim, > > Thanks for the heads-up. > > Please ensure that any BOF you hold does not conflict with either the MPLS > or CCAMP working group meetins. I predict that many people will wish to > attend all three meetings. > > After a preliminary reading of draft-chakravorty-6lsa-01.txt it seems to > me that what you are suggesting has massive overlap with MPLS and GMPLS. > That you are proposing a form of layer 3 switching which is not part of > MPLS or GMPLS (but which has been suggested at several previous IETF > meetings) is a fairly minor fact since the data plane operation of > swapping and switching is unchanged. That is, you are proposing a new form > of labeling. > > The bigger difference comes in how the labels are distributed, and in this > context, one might ask what is wrong with existing label distribution > schemes. > > But clearly I need to read in more detail. > > Cheers, > Adrian > > ----- Original Message ----- > From: "Bound, Jim" > To: > Cc: > Sent: Sunday, February 27, 2005 7:34 PM > Subject: 6LSA IETF Drafts > > > Folks, > > See below draft and two attached that will be available after the IETF. > It provides a solution for IPv6 Label Switch Architecture that does not > compete with MPLS or QOS work in progress in the industry at ITU, etc. > > http://ietf.org/internet-drafts/draft-chakravorty-6lsa-01.txt > > If some of you would do me a favor and review and send comments to Sham > Chakravorty schakra@mitre.org, Jim.Bound@nav6tf.org, and Kevin Zhang > kzhang@mitre.org I would appreciate it. We will have a BOF most likely > on 6LSA at the Paris meeting to see if this would be its own working > group. We will set up industry list for technical persons to work on it > until then if we get enough responses. I am pretty sure we should do > this here in the IETF not go to the ITU. Also we will be at the > Minneapolis IETF so if you have in person comments that is appreciate > too. > > Thanks > /jim > > > > > > >>_______________________________________________ >>Rtgwg mailing list >>Rtgwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/rtgwg >> > > > > -------------------------------------------------------------------- > 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 May 03 06:36:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSulZ-00046w-Nn; Tue, 03 May 2005 06:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSulX-00046r-Eb for ipv6@megatron.ietf.org; Tue, 03 May 2005 06:36:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28392 for ; Tue, 3 May 2005 06:36:32 -0400 (EDT) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuzO-0004l2-1h for ipv6@ietf.org; Tue, 03 May 2005 06:50:55 -0400 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j43AaO4G197538 for ; Tue, 3 May 2005 10:36:24 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j43AaODK130674 for ; Tue, 3 May 2005 11:36:24 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j43AaNFG013509 for ; Tue, 3 May 2005 11:36:23 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j43AaNaD013498; Tue, 3 May 2005 11:36:23 +0100 Received: from zurich.ibm.com (sig-9-145-129-244.de.ibm.com [9.145.129.244]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA46038; Tue, 3 May 2005 12:36:22 +0200 Message-ID: <42775427.3060503@zurich.ibm.com> Date: Tue, 03 May 2005 12:36:23 +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: Kit Plummer References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> 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: dwmalone@maths.tcd.ie, ipv6@ietf.org, "Bound, Jim" Subject: Re: Flow Label consistency question 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 Kit Plummer wrote: > > On Apr 24, 2005, at 8:55 AM, Ran Liebermann wrote: > >> Ofcourse if the label will also be used to classify traffic for >> diffserv then this is one more reason for SPs to override the label to >> zero on all ingress traffic from customers. >> > > If this is the case, and I hope it is...wouldn't is simply make more > sense for the SP to ignore the FL all together? Therefore, if the FL > were pertinent on the other end... The diffserv use case would use an e2e flow label to allow all diffserv classifiers along the path to correctly reclassify the packet, even if the protocol and port numbers are obscured by encryption. That only works if the flow label value is preserved right up to the last router on the last LAN on the path. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 03 09:42:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSxfk-00088A-Rf; Tue, 03 May 2005 09:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSxfi-00087w-19 for ipv6@megatron.ietf.org; Tue, 03 May 2005 09:42:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17906 for ; Tue, 3 May 2005 09:42:44 -0400 (EDT) Received: from tus-gate2.raytheon.com ([199.46.245.231]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSxta-00018e-Cy for ipv6@ietf.org; Tue, 03 May 2005 09:57:07 -0400 Received: from ds02t00.directory.ray.com (ds02t00.directory.ray.com [147.25.154.117]) by tus-gate2.raytheon.com (8.12.10/8.12.10) with ESMTP id j43DgPdE001448; Tue, 3 May 2005 06:42:34 -0700 (MST) Received: from ds02t00 (localhost [127.0.0.1]) by ds02t00.directory.ray.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j43DgM2u013981; Tue, 3 May 2005 13:42:22 GMT Received: from ds02t00.directory.ray.com with LMTP by ds02t00 (2.0.6/sieved-2-0-build-559); Tue, 3 May 2005 13:42:22 +0000 Received: from tu2-mta01.rsc.raytheon.com (tu2-mta01.RSC.RAYTHEON.COM [147.24.232.78]) by ds02t00.directory.ray.com (Switch-3.1.7/Switch-3.1.0) with ESMTP id j43Dg6mW013825 sender christopher_plummer@raytheon.com; Tue, 3 May 2005 13:42:06 GMT Received: from [147.24.71.112] ([147.24.71.112]) by tu2-msg03.rsc.raytheon.com (Lotus Domino Release 6.5.4) with ESMTP id 2005050306420391-68 ; Tue, 3 May 2005 06:42:03 -0700 In-Reply-To: <42775427.3060503@zurich.ibm.com> References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <42775427.3060503@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v728) Message-Id: <5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> From: Kit Plummer Date: Tue, 3 May 2005 06:42:23 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.728) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-SPAM: 0.00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: dwmalone@maths.tcd.ie, ipv6@ietf.org, "Bound, Jim" Subject: Re: Flow Label consistency question 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 May 3, 2005, at 3:36 AM, Brian E Carpenter wrote: > Kit Plummer wrote: > >> On Apr 24, 2005, at 8:55 AM, Ran Liebermann wrote: >> >>> Ofcourse if the label will also be used to classify traffic for >>> diffserv then this is one more reason for SPs to override the >>> label to >>> zero on all ingress traffic from customers. >>> >>> >> If this is the case, and I hope it is...wouldn't is simply make >> more sense for the SP to ignore the FL all together? Therefore, >> if the FL were pertinent on the other end... >> > > The diffserv use case would use an e2e flow label to allow all > diffserv > classifiers along the path to correctly reclassify the packet, even if > the protocol and port numbers are obscured by encryption. That only > works > if the flow label value is preserved right up to the last router on > the > last LAN on the path. > > Brian > Brian, Just trying to see this straight...and I think I am understanding correctly. But, my question is why would a SP override the label, if the label is to provide information from a classification perspective? The answer as I see is that they shouldn't...and as you pointed out the necessity for preservation from true e2e. Flow labeling is a very interesting topic to me/us. Cool stuff. Thanks. Kit ------------------------------------------------------------------------ Kit Plummer Operations Research and System Performance Dept. Raytheon Missile Systems -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 03 10:56:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSyoq-0007Z8-Ux; Tue, 03 May 2005 10:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSyop-0007Y0-9H for ipv6@megatron.ietf.org; Tue, 03 May 2005 10:56:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26522 for ; Tue, 3 May 2005 10:56:12 -0400 (EDT) Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSz2i-00034S-40 for ipv6@ietf.org; Tue, 03 May 2005 11:10:37 -0400 Received: from [199.212.90.16] (helo=[199.212.90.16]) by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1DSyoj-000Jc7-9x for ipv6@ietf.org; Tue, 03 May 2005 14:56:09 +0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <200505021952.PAA26962@ietf.org> References: <200505021952.PAA26962@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Date: Tue, 3 May 2005 10:55:35 -0400 To: ipv6@ietf.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-03.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 2 May 2005, at 15:52, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Version 6 Working Group Working > Group of the IETF. > > Title : IP Version 6 Addressing Architecture > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipv6-addr-arch-v4-03.txt > Pages : 26 > Date : 2005-5-2 The changes in this revision (to remove the prohibition on host-based anycast in IPv6) are exactly what is needed, I think. Excellent. Joe -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 03 12:14:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT02R-0006Wf-4t; Tue, 03 May 2005 12:14:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT02O-0006WV-Dc for ipv6@megatron.ietf.org; Tue, 03 May 2005 12:14:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05289 for ; Tue, 3 May 2005 12:14:17 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT0GH-0005QB-6d for ipv6@ietf.org; Tue, 03 May 2005 12:28:43 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11233277; Tue, 03 May 2005 12:13:33 -0400 In-Reply-To: <5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <42775427.3060503@zurich.ibm.com> <5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <1d1add7bd376e976c6a7316fcf7c83a1@innovationslab.net> From: Brian Haberman Date: Tue, 3 May 2005 12:13:31 -0400 To: Kit Plummer X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: dwmalone@maths.tcd.ie, Brian E Carpenter , ipv6@ietf.org, "Bound, Jim" Subject: Re: Flow Label consistency question 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="===============0979135455==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0979135455== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--609341279; protocol="application/pkcs7-signature" --Apple-Mail-3--609341279 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 3, 2005, at 9:42, Kit Plummer wrote: > On May 3, 2005, at 3:36 AM, Brian E Carpenter wrote: > >> Kit Plummer wrote: >> >>> On Apr 24, 2005, at 8:55 AM, Ran Liebermann wrote: >>> >>>> Ofcourse if the label will also be used to classify traffic for >>>> diffserv then this is one more reason for SPs to override the label >>>> to >>>> zero on all ingress traffic from customers. >>>> >>>> >>> If this is the case, and I hope it is...wouldn't is simply make more >>> sense for the SP to ignore the FL all together? Therefore, if the >>> FL were pertinent on the other end... >>> >> >> The diffserv use case would use an e2e flow label to allow all >> diffserv >> classifiers along the path to correctly reclassify the packet, even if >> the protocol and port numbers are obscured by encryption. That only >> works >> if the flow label value is preserved right up to the last router on >> the >> last LAN on the path. >> >> Brian >> > > Brian, > > Just trying to see this straight...and I think I am understanding > correctly. But, my question is why would a SP override the label, if > the label is to provide information from a classification perspective? > The answer as I see is that they shouldn't...and as you pointed out > the necessity for preservation from true e2e. > I can't speak for Brian, but I understand what he is saying. The FL is the only end-to-end field used for classification. The Traffic Class field will/ can be modified at the border of each service provider. The FL remains constant and can be input into that classification process. Regards, Brian --Apple-Mail-3--609341279 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTAzMTYxMzMyWjAjBgkqhkiG9w0B CQQxFgQUkQT8aeQTqbQMWDLY2hqY4EUx5akweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAhH1oOfCI4JfNY8fmbeqWtrIDJXs5jQQNScNfeuaoWKhKNk6PkD7LQK24Rkc5wgkMhaWj ofHSE0TlT9GtTaspCKVQZH4YcvDrxc7EyTtewedny//j1ecPl8eQrsTidu5Gd3LTeiXw+WTAg2yU vemDl5aNDUZRlyGthGnrzvFTDA+3TOWUtAlJ/vlVhD8oNBr9BHx+UphrLj4PgxjPlFTVCbHElSE5 LEu3/apCMOFfCBNS6q8OkhwHnU3zej77XyEaYXXQc19foiLFblrcpifzmXQwtjFMcPGPY/TSy2UT vOEUOyUIBWP7fHMhUuvWfKPOw4oxxFissdbrkb1MPx5o5QAAAAAAAA== --Apple-Mail-3--609341279-- --===============0979135455== 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 -------------------------------------------------------------------- --===============0979135455==-- From ipv6-bounces@ietf.org Wed May 04 04:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTFFw-00005r-PF; Wed, 04 May 2005 04:29:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT6Me-0001eQ-DC; Tue, 03 May 2005 18:59:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21148; Tue, 3 May 2005 18:59:37 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT6ab-0002Hd-Lm; Tue, 03 May 2005 19:14:07 -0400 Received: from du-069-0067.access.clara.net ([217.158.132.67] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DT6MX-000Fx6-Ir; Tue, 03 May 2005 23:59:34 +0100 Message-ID: <097301c55034$0de54d60$1c849ed9@Puppy> From: "Adrian Farrel" To: "Brian E Carpenter" References: <9C422444DE99BC46B3AD3C6EAFC9711B087EE13D@tayexc13.americas.cpqcorp.net> <04fc01c54bf9$f7083fa0$1c849ed9@Puppy> <4277530A.3070901@zurich.ibm.com> Date: Wed, 4 May 2005 00:01:32 +0100 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 May 2005 04:29:18 -0400 Cc: ipv6@ietf.org, rtgwg@ietf.org Subject: Re: 6LSA IETF Drafts X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel 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 Brian, > There is one important difference, which is that the M in MPLS > stands for multiprotocol. A label switched architecture for > one particular network layer protocol is not the same as > a multiprotocol architecture. Very true. Limiting the scope allows the potential of optimizations. OTH, the M in MPLS stands for multiprotocol. And the G in GMPLS stands for generalized. So one might assume that they are capable of handling IPv6 already. But I think there is a little fuzziness in your statement. :-) I don't think there is such a thing as "a label switched architecture for one particular network layer protocol." I mean: what is a protocol? What the proposal appears to have is: - A definition of a way to label layer 3 packets so that they can be switched. - A way to exchange and synchronize labels between 6LSRs. I think the first point may fly (and it is not disimilar to suggestions in previous IETF meetings, although they were more focused on IPv4). I am interested to know how (and why) the second point differs from the label distribution techniques developed in the MPLS and CCAMP WGs. Cheers, Adrian > > Jim, > > > > Thanks for the heads-up. > > > > Please ensure that any BOF you hold does not conflict with either the MPLS > > or CCAMP working group meetins. I predict that many people will wish to > > attend all three meetings. > > > > After a preliminary reading of draft-chakravorty-6lsa-01.txt it seems to > > me that what you are suggesting has massive overlap with MPLS and GMPLS. > > That you are proposing a form of layer 3 switching which is not part of > > MPLS or GMPLS (but which has been suggested at several previous IETF > > meetings) is a fairly minor fact since the data plane operation of > > swapping and switching is unchanged. That is, you are proposing a new form > > of labeling. > > > > The bigger difference comes in how the labels are distributed, and in this > > context, one might ask what is wrong with existing label distribution > > schemes. > > > > But clearly I need to read in more detail. > > > > Cheers, > > Adrian > > > > ----- Original Message ----- > > From: "Bound, Jim" > > To: > > Cc: > > Sent: Sunday, February 27, 2005 7:34 PM > > Subject: 6LSA IETF Drafts > > > > > > Folks, > > > > See below draft and two attached that will be available after the IETF. > > It provides a solution for IPv6 Label Switch Architecture that does not > > compete with MPLS or QOS work in progress in the industry at ITU, etc. > > > > http://ietf.org/internet-drafts/draft-chakravorty-6lsa-01.txt > > > > If some of you would do me a favor and review and send comments to Sham > > Chakravorty schakra@mitre.org, Jim.Bound@nav6tf.org, and Kevin Zhang > > kzhang@mitre.org I would appreciate it. We will have a BOF most likely > > on 6LSA at the Paris meeting to see if this would be its own working > > group. We will set up industry list for technical persons to work on it > > until then if we get enough responses. I am pretty sure we should do > > this here in the IETF not go to the ITU. Also we will be at the > > Minneapolis IETF so if you have in person comments that is appreciate > > too. > > > > Thanks > > /jim > > > > > > > > > > > > > >>_______________________________________________ > >>Rtgwg mailing list > >>Rtgwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/rtgwg > >> > > > > > > > > -------------------------------------------------------------------- > > 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 May 04 05:19:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTG2j-0007B3-8x; Wed, 04 May 2005 05:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTG2g-0007Ag-RM for ipv6@megatron.ietf.org; Wed, 04 May 2005 05:19:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09580 for ; Wed, 4 May 2005 05:19:40 -0400 (EDT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTGGi-0007ZA-FI for ipv6@ietf.org; Wed, 04 May 2005 05:34:15 -0400 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j449JT78218316 for ; Wed, 4 May 2005 09:19:30 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j449JSdT119180 for ; Wed, 4 May 2005 10:19:28 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j449JS5F006194 for ; Wed, 4 May 2005 10:19:28 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j449JS1D006189; Wed, 4 May 2005 10:19:28 +0100 Received: from zurich.ibm.com (sig-9-145-248-129.de.ibm.com [9.145.248.129]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA26214; Wed, 4 May 2005 11:19:27 +0200 Message-ID: <42779B99.5080006@zurich.ibm.com> Date: Tue, 03 May 2005 17:41:13 +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: Kit Plummer References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <42775427.3060503@zurich.ibm.com> <5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> In-Reply-To: <5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: dwmalone@maths.tcd.ie, ipv6@ietf.org, "Bound, Jim" Subject: Re: Flow Label consistency question 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 Kit Plummer wrote: > On May 3, 2005, at 3:36 AM, Brian E Carpenter wrote: > >> Kit Plummer wrote: >> >>> On Apr 24, 2005, at 8:55 AM, Ran Liebermann wrote: >>> >>>> Ofcourse if the label will also be used to classify traffic for >>>> diffserv then this is one more reason for SPs to override the label to >>>> zero on all ingress traffic from customers. >>>> >>>> >>> If this is the case, and I hope it is...wouldn't is simply make >>> more sense for the SP to ignore the FL all together? Therefore, if >>> the FL were pertinent on the other end... >>> >> >> The diffserv use case would use an e2e flow label to allow all diffserv >> classifiers along the path to correctly reclassify the packet, even if >> the protocol and port numbers are obscured by encryption. That only >> works >> if the flow label value is preserved right up to the last router on the >> last LAN on the path. >> >> Brian >> > > Brian, > > Just trying to see this straight...and I think I am understanding > correctly. But, my question is why would a SP override the label, if > the label is to provide information from a classification perspective? > The answer as I see is that they shouldn't...and as you pointed out the > necessity for preservation from true e2e. The point is that (at the ISPs' request) the diffserv model allows each ISP along the path to apply a different policy - so a packet marked for EF treatment inside one ISP might be marked for AF treatment inside another ISP. (You can argue that would be stupid, but that's what the diffserv WG heard from the ISPs.) So different SPs will interpret the same label differently. 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 May 04 05:37:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGJw-0007F6-Mc; Wed, 04 May 2005 05:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGJu-0007Ed-5J for ipv6@megatron.ietf.org; Wed, 04 May 2005 05:37:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11390 for ; Wed, 4 May 2005 05:37:27 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTGXy-00080o-35 for ipv6@ietf.org; Wed, 04 May 2005 05:52:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4496hM14066 for ; Wed, 4 May 2005 02:06:43 -0700 X-mProtect: <200505040906> Nokia Silicon Valley Messaging Protection Received: from dunira-pool151196.europe.nokia.com (172.25.151.196, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdHyHrs5; Wed, 04 May 2005 02:06:40 PDT Message-Id: <6.2.1.2.2.20050504023601.02f409f0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 02:36:42 -0700 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: Fwd: Last Call: 'Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream' 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 FYI. This includes IPv6 support. Bob >To: IETF-Announce >From: The IESG >Date: Mon, 02 May 2005 14:56:21 -0400 >X-Spam-Score: 0.0 (/) >X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >Cc: ipdvb@erg.abdn.ac.uk >Subject: Last Call: 'Ultra Lightweight Encapsulation (ULE) for transmission > of > IP datagrams over an MPEG-2 Transport Stream' to Proposed Standard >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: iesg@ietf.org >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org >X-OriginalArrivalTime: 02 May 2005 19:03:51.0587 (UTC) >FILETIME=[ADBB5730:01C54F49] > >The IESG has received a request from the IP over DVB WG to consider the >following document: > >- 'Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams >over > an MPEG-2 Transport Stream ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-16. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ule-05.txt > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 04 05:44:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGQR-0000YB-6l; Wed, 04 May 2005 05:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGQN-0000Wd-7S for ipv6@megatron.ietf.org; Wed, 04 May 2005 05:44:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12367 for ; Wed, 4 May 2005 05:44:06 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTGeN-0008Gc-Ni for ipv6@ietf.org; Wed, 04 May 2005 05:58:41 -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 j449hbi3018256; Wed, 4 May 2005 10:43:37 +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 KAA20222; Wed, 4 May 2005 10:43:35 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j449hZr32427; Wed, 4 May 2005 10:43:35 +0100 Date: Wed, 4 May 2005 10:43:35 +0100 From: Tim Chown To: Brian E Carpenter Message-ID: <20050504094335.GF31529@login.ecs.soton.ac.uk> Mail-Followup-To: Brian E Carpenter , Kit Plummer , dwmalone@maths.tcd.ie, ipv6@ietf.org, "Bound, Jim" References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <42775427.3060503@zurich.ibm.com> <5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> <42779B99.5080006@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42779B99.5080006@zurich.ibm.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dwmalone@maths.tcd.ie, "Bound, Jim" , ipv6@ietf.org Subject: Re: Flow Label consistency question 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, May 03, 2005 at 05:41:13PM +0200, Brian E Carpenter wrote: > The point is that (at the ISPs' request) the diffserv model allows > each ISP along the path to apply a different policy - so a packet > marked for EF treatment inside one ISP might be marked for AF > treatment inside another ISP. (You can argue that would be stupid, but > that's what the diffserv WG heard from the ISPs.) So different SPs will > interpret the same label differently. How weird :) In the academic community, a lot of effort has been put in to agree some common DSCP semantics; this has been particulary useful for LBE, where end-to-end immutability of the DSCP is highly desirable (DSCP=8). If an ISP wants to apply local marking then it can, but one would hope the value would be restored on exit from the ISP's scope. I'm not aware of any research network that changes the value. You can test this with the traceroute -t option to set a DSCP value, and it'll report any change along the path. I tried this to a US commercial server, and no DSCP change was reported. WOuld be interesting to see who is seeing this happen in practice. -- 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 May 04 05:46:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGSo-0001ly-38; Wed, 04 May 2005 05:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTGSm-0001kv-GY for ipv6@megatron.ietf.org; Wed, 04 May 2005 05:46:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12538 for ; Wed, 4 May 2005 05:46:37 -0400 (EDT) Received: from jive.softhome.net ([66.54.152.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTGgo-0008K5-HJ for ipv6@ietf.org; Wed, 04 May 2005 06:01:12 -0400 Received: (qmail 7085 invoked by uid 417); 4 May 2005 09:46:26 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 4 May 2005 09:46:26 -0000 Received: from mehr ([132.70.222.156]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 04 May 2005 03:46:20 -0600 Message-ID: <012501c5508d$283993c0$0401a8c0@mtc.ki.se> From: "Eric Klein" To: ipv6@ietf.org References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net><20050422104649.GA34348@walton.maths.tcd.ie><8c19328e050424085579a2ac20@mail.gmail.com><42775427.3060503@zurich.ibm.com><5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> <42779B99.5080006@zurich.ibm.com> Date: Wed, 4 May 2005 12:39:18 +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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: Re: Flow Label consistency question 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 Brian E Carpenter Wrote > The point is that (at the ISPs' request) the diffserv model allows > each ISP along the path to apply a different policy - so a packet > marked for EF treatment inside one ISP might be marked for AF > treatment inside another ISP. (You can argue that would be stupid, but > that's what the diffserv WG heard from the ISPs.) So different SPs will > interpret the same label differently. Do they change the original lable, or just apply diffrent policies on the same lable? If it is the first I can see many problems, but if it is the second I can understand why they would want to control traffic transversing (or even terminating) on their network diffrently than the originating network. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 04 06:59:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTHbi-0005z6-B4; Wed, 04 May 2005 06:59:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTHbf-0005sT-4K for ipv6@megatron.ietf.org; Wed, 04 May 2005 06:59:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19011 for ; Wed, 4 May 2005 06:59:52 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTHpi-0001eF-Su for ipv6@ietf.org; Wed, 04 May 2005 07:14:28 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11268468; Wed, 04 May 2005 06:59:13 -0400 In-Reply-To: <012501c5508d$283993c0$0401a8c0@mtc.ki.se> References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net><20050422104649.GA34348@walton.maths.tcd.ie><8c19328e050424085579a2ac20@mail.gmail.com><42775427.3060503@zurich.ibm.com><5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> <42779B99.5080006@zurich.ibm.com> <012501c5508d$283993c0$0401a8c0@mtc.ki.se> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <17f79012d1b9a8ae6c62e5b89f0d7124@innovationslab.net> From: Brian Haberman Date: Wed, 4 May 2005 06:59:13 -0400 To: "Eric Klein" X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipv6@ietf.org Subject: Re: Flow Label consistency question 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="===============1814862696==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1814862696== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--541799358; protocol="application/pkcs7-signature" --Apple-Mail-1--541799358 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 4, 2005, at 5:39, Eric Klein wrote: > Brian E Carpenter Wrote >> The point is that (at the ISPs' request) the diffserv model allows >> each ISP along the path to apply a different policy - so a packet >> marked for EF treatment inside one ISP might be marked for AF >> treatment inside another ISP. (You can argue that would be stupid, but >> that's what the diffserv WG heard from the ISPs.) So different SPs >> will >> interpret the same label differently. > > Do they change the original lable, or just apply diffrent policies on > the > same lable? The Flow Label is unaffected. The Traffic Class field can be modified at the ISP marking device. Regards, Brian --Apple-Mail-1--541799358 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTA0MTA1OTE0WjAjBgkqhkiG9w0B CQQxFgQUTCtzpa9ZR+ewPO59UMmUtDBoCq8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAun1R8x+QQ1KbIu3ws3OJQj7rA24B+7JUCrZzp6JCon7TNvgrFvi1bNP4C1YYUubakBAr Hwb97AQxkYNSSbP3LP/dox1wOlWxA1ZVZnVLCTuvOpiG8KtLqIP27ttIeCiEy+kGrggtwq3mKvSV pAc7eGTgphkGGaBQTDif0h9Ydq5kBE+75YjtKLMnM2xgZFwwSQRUmTZEeWU1JBdeatCprFtklMoU j7T77tcV1VViS3Csc4M8nf470v237pycNCtyBMhrVqjJk+Yux9JFFJsPaoVznAj1K6db2irrC4Ug q68OiF0lMXJbKWcGSBfDiHgPhT+JRI/xwC+z4zYJx6IyawAAAAAAAA== --Apple-Mail-1--541799358-- --===============1814862696== 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 -------------------------------------------------------------------- --===============1814862696==-- From ipv6-bounces@ietf.org Wed May 04 08:54:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJOd-0002Di-UQ; Wed, 04 May 2005 08:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJOY-0002C1-73 for ipv6@megatron.ietf.org; Wed, 04 May 2005 08:54:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02560 for ; Wed, 4 May 2005 08:54:28 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTJcc-0005EY-LV for ipv6@ietf.org; Wed, 04 May 2005 09:09:04 -0400 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j44CsJSp146890 for ; Wed, 4 May 2005 12:54:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j44CsJ17266788 for ; Wed, 4 May 2005 14:54:19 +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 j44CsI3U000815 for ; Wed, 4 May 2005 14:54:19 +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 j44CsILn000803; Wed, 4 May 2005 14:54:18 +0200 Received: from zurich.ibm.com (sig-9-145-248-129.de.ibm.com [9.145.248.129]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA25794; Wed, 4 May 2005 14:54:17 +0200 Message-ID: <4278C5F5.1050507@zurich.ibm.com> Date: Wed, 04 May 2005 14:54:13 +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: Tim Chown References: <936A4045C332714F975800409DE09240166FFF@tayexc14.americas.cpqcorp.net> <20050422104649.GA34348@walton.maths.tcd.ie> <8c19328e050424085579a2ac20@mail.gmail.com> <42775427.3060503@zurich.ibm.com> <5A6F1E0A-8722-453B-A23E-84ACBFF46003@raytheon.com> <42779B99.5080006@zurich.ibm.com> <20050504094335.GF31529@login.ecs.soton.ac.uk> In-Reply-To: <20050504094335.GF31529@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: dwmalone@maths.tcd.ie, "Bound, Jim" , ipv6@ietf.org Subject: Re: Flow Label consistency question 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 Tim Chown wrote: > On Tue, May 03, 2005 at 05:41:13PM +0200, Brian E Carpenter wrote: > > >>The point is that (at the ISPs' request) the diffserv model allows >>each ISP along the path to apply a different policy - so a packet >>marked for EF treatment inside one ISP might be marked for AF >>treatment inside another ISP. (You can argue that would be stupid, but >>that's what the diffserv WG heard from the ISPs.) So different SPs will >>interpret the same label differently. > > > How weird :) The example I chose was deliberately weird to indicate the principle. Perhaps a more realistic example is if ISP A marks VoIP traffic with the EF code point, and ISP B marks it with Class Selector 5 (formerly known as Precedence 5). > > In the academic community, a lot of effort has been put in to agree some > common DSCP semantics; this has been particulary useful for LBE, where > end-to-end immutability of the DSCP is highly desirable (DSCP=8). Well, it wouldn't be needed if everyone agreed that all sources would use Flow Label = 8 for all LBE flows, but different domains chose to use (say) DSCP=0 or DSCP=8 for LBE traffic. > > If an ISP wants to apply local marking then it can, but one would hope > the value would be restored on exit from the ISP's scope. No, that's explicitly not a requirement in the diffserv architecture. And it isn't algorthmically possible without adding a signalling protocol - there are no 1:1 correspondences rules to invoke. > > I'm not aware of any research network that changes the value. > > You can test this with the traceroute -t option to set a DSCP value, and > it'll report any change along the path. > > I tried this to a US commercial server, and no DSCP change was reported. > WOuld be interesting to see who is seeing this happen in practice. What I'm telling you is the way we were more or less told to design diffserv by the operator community. For what people are now thinking, see draft-ietf-tsvwg-diffserv-service-classes-00.txt. Given this architecture, IPv6 has the advantage of the e2e Flow Label, which IPv4 doesn't. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 06 09:18:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU2j7-0004gX-SV; Fri, 06 May 2005 09:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU2j4-0004dR-7O; Fri, 06 May 2005 09:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13226; Fri, 6 May 2005 09:18:40 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU2xX-0003pD-ST; Fri, 06 May 2005 09:33:41 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IG200ANCL445R@szxga01-in.huawei.com>; Fri, 06 May 2005 21:21:41 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IG200ANQL442Z@szxga01-in.huawei.com>; Fri, 06 May 2005 21:21:40 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IG2002QGLAHNC@szxml01-in.huawei.com>; Fri, 06 May 2005 21:25:31 +0800 (CST) Date: Fri, 06 May 2005 18:48:32 +0530 From: Keshava Ayanur To: ipv6@ietf.org, mip6@ietf.org Message-id: <000001c5523e$1ab581c0$b504120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: 'Keshav' Subject: Anycast Address becoming Multicast address .... X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1257686669==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============1257686669== Content-type: multipart/alternative; boundary="Boundary_(ID_D8e7vK12IzTJGV9TgT3gbg)" This is a multi-part message in MIME format. --Boundary_(ID_D8e7vK12IzTJGV9TgT3gbg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, When the global unicast address with prefix 2 (ex: DADA::100/2) is given for the interface, Mobile IPV6 anycast address corresponding to this should be as below( RFC 2526). Format of Reserved Subnet Anycast Addresses: | n bits | 121-n bits | 7 bits | +---------------------------------+-----------.-------+------------ + | subnet prefix | 111..111111 | anycast ID | +---------------------------------+------------------+----------- -+ | interface identifier field | So MIP6 any cast address corresponding to this global unicast address (DADA::100/2) will be FFFF:FFFF:FFFF:FFFF:FFFE as the subnet prefix will 11 (prefix length is 2 only) This FFFF:FFFF:FFFF:FFFF:FFFE is a multicast address. But as per RFC 3513 IPv6 Addressing Architecture, "Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats" Can someone clarify this in-discrepancy? Regards, keshava --Boundary_(ID_D8e7vK12IzTJGV9TgT3gbg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

When the global unicast address with prefix 2 (ex: DADA::100/2) is given for the interface, Mobile IPV6 anycast address corresponding to this should be as below( RFC 2526).

 

 Format of Reserved Subnet Anycast Addresses:

 

   |              n bits            |    121-n bits  |   7 bits   |

  +---------------------------------+-----------.-------+------------ +

   |      subnet prefix         | 111..111111 | anycast ID |

  +---------------------------------+------------------+----------- -+

                                      |   interface identifier field  |

 

So MIP6 any cast address corresponding to this global unicast address (DADA::100/2) will be

FFFF:FFFF:FFFF:FFFF:FFFE as  the subnet prefix will 11 (prefix length is 2 only)

 

This  FFFF:FFFF:FFFF:FFFF:FFFE is a multicast address.

           

 

But as per RFC 3513 IPv6 Addressing Architecture,

 “Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats”

 

            Can someone clarify this in-discrepancy?

 

 

Regards,

keshava

           

--Boundary_(ID_D8e7vK12IzTJGV9TgT3gbg)-- --===============1257686669== 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 -------------------------------------------------------------------- --===============1257686669==-- From ipv6-bounces@ietf.org Fri May 06 15:44:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU8kL-0003Nv-KF; Fri, 06 May 2005 15:44:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU8kH-0003NI-U0; Fri, 06 May 2005 15:44:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29056; Fri, 6 May 2005 15:44:19 -0400 (EDT) Message-Id: <200505061944.PAA29056@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 06 May 2005 15:44:19 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-11.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Information Queries Author(s) : M. Crawford, B. Haberman Filename : draft-ietf-ipngwg-icmp-name-lookups-11.txt Pages : 14 Date : 2005-5-6 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-6153237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-6153237.I-D@ietf.org> --OtherAccess-- --NextPart 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 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Fri May 06 20:07:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUCr5-0003l5-A3; Fri, 06 May 2005 20:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUCr4-0003kx-03; Fri, 06 May 2005 20:07:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24758; Fri, 6 May 2005 20:07:35 -0400 (EDT) Received: from farside.isc.org ([204.152.187.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUD5d-0002lg-QU; Fri, 06 May 2005 20:22:43 -0400 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id F30F2677EF; Sat, 7 May 2005 00:07:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j4706UQr057192; Sat, 7 May 2005 10:06:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200505070006.j4706UQr057192@drugs.dv.isc.org> To: keshavak@huawei.com From: Mark Andrews In-reply-to: Your message of "Fri, 06 May 2005 18:48:32 +0530." <000001c5523e$1ab581c0$b504120a@china.huawei.com> Date: Sat, 07 May 2005 10:06:30 +1000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mip6@ietf.org, ipv6@ietf.org, 'Keshav' Subject: Re: Anycast Address becoming Multicast address .... 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, > > When the global unicast address with prefix 2 (ex: DADA::100/2) is given for > the interface, Mobile IPV6 anycast address corresponding to this should be > as below( RFC 2526). > > > > Format of Reserved Subnet Anycast Addresses: > > > > | n bits | 121-n bits | 7 bits | > > +---------------------------------+-----------.-------+------------ + > > | subnet prefix | 111..111111 | anycast ID | > > +---------------------------------+------------------+----------- -+ > > | interface identifier field | > > > > So MIP6 any cast address corresponding to this global unicast address > (DADA::100/2) will be > > FFFF:FFFF:FFFF:FFFF:FFFE as the subnet prefix will 11 (prefix length is 2 > only) > > > > This FFFF:FFFF:FFFF:FFFF:FFFE is a multicast address. > > > > > > But as per RFC 3513 IPv6 Addressing Architecture, > > "Anycast addresses are allocated from the unicast address space, using any > of the defined unicast address formats" > > > > Can someone clarify this in-discrepancy? > > > > > > Regards, > > keshava Well in 2373 the minimum prefix len was 3 for the above address. Basically all the prefixes in 2373 has enough bits to distinguish them from a multicast address, i.e. the prefix contained atleast one "zero" bit. They also contained enough infomation to distinguish it from a reserved address, i.e. one "one" bit. The simplest thing may be to say the minimum prefix length is 8. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun May 08 00:00:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUcyH-0002Ro-BC; Sun, 08 May 2005 00:00:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUcyF-0002Ri-13 for ipv6@megatron.ietf.org; Sun, 08 May 2005 00:00:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15457 for ; Sun, 8 May 2005 00:00:44 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUdD3-00087u-P3 for ipv6@ietf.org; Sun, 08 May 2005 00:16:07 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 5822478 for ; Sun, 8 May 2005 00:00:33 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 08 May 2005 00:00:32 -0400 Message-Id: <20050508040033.5822478@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 --------+------+--------+----------+------------------------ 18.18% | 4 | 17.57% | 22825 | brc@zurich.ibm.com 9.09% | 2 | 13.51% | 17553 | brian@innovationslab.net 9.09% | 2 | 8.98% | 11661 | internet-drafts@ietf.org 4.55% | 1 | 9.59% | 12461 | mukesh.k.gupta@nokia.com 4.55% | 1 | 9.31% | 12093 | keshavaak@huawei.com 4.55% | 1 | 5.11% | 6642 | adrian@olddog.co.uk 4.55% | 1 | 4.88% | 6334 | soohong.park@samsung.com 4.55% | 1 | 4.01% | 5212 | christopher_plummer@raytheon.com 4.55% | 1 | 3.75% | 4869 | tjc@ecs.soton.ac.uk 4.55% | 1 | 3.64% | 4726 | bob.hinden@nokia.com 4.55% | 1 | 3.61% | 4692 | mark_andrews@isc.org 4.55% | 1 | 3.13% | 4069 | sra+ipng@hactrn.net 4.55% | 1 | 2.98% | 3877 | ericlklein@softhome.net 4.55% | 1 | 2.80% | 3635 | mailman-owner@ietf.org 4.55% | 1 | 2.51% | 3266 | jabley@isc.org 4.55% | 1 | 2.35% | 3052 | iesg-secretary@ietf.org 4.55% | 1 | 2.26% | 2931 | margaret@thingmagic.com --------+------+--------+----------+------------------------ 100.00% | 22 |100.00% | 129898 | 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 May 09 10:57:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV9h9-0002tf-SU; Mon, 09 May 2005 10:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV9h7-0002tS-Cb for ipv6@megatron.ietf.org; Mon, 09 May 2005 10:57:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22281 for ; Mon, 9 May 2005 10:57:15 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV9wE-0003V7-BM for ipv6@ietf.org; Mon, 09 May 2005 11:12:55 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11460647; Mon, 09 May 2005 10:56:36 -0400 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <200505061944.PAA29056@ietf.org> References: <200505061944.PAA29056@ietf.org> Message-Id: <0fb3601844cbf3e3999b0bf94bda49a2@innovationslab.net> From: Brian Haberman Date: Mon, 9 May 2005 10:56:35 -0400 To: IPv6 WG X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-11.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="===============1087933588==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1087933588== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--95557856; protocol="application/pkcs7-signature" --Apple-Mail-8--95557856 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit All, A refreshed version of the ICMP Name Lookups draft is available. I would especially like WG members who have implementations to review the draft and point out discrepancies between the spec and their code (e.g. unimplemented features). There are several comments that I will be looking to resolve prior to the publication of a new version. Those are: 1. Is there a need to delay the sending of a Query addressed to an anycast address? 2. Clarification in the functionality of the NOOP Please send comments to me or the mailing list. Regards, Brian On May 6, 2005, at 15:44, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Version 6 Working Group Working > Group of the IETF. > > Title : IPv6 Node Information Queries > Author(s) : M. Crawford, B. Haberman > Filename : draft-ietf-ipngwg-icmp-name-lookups-11.txt > Pages : 14 > Date : 2005-5-6 > > This document describes a protocol for asking an IPv6 node to supply > certain network information, such as its hostname or fully-qualified > domain name. IPv6 implementation experience has shown that direct > queries for a hostname are useful, and a direct query mechanism for > other information has been found useful in serverless environments > and for debugging. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name- > lookups-11.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipngwg-icmp-name-lookups-11.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-11.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-5-6153237.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > --Apple-Mail-8--95557856 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTA5MTQ1NjM1WjAjBgkqhkiG9w0B CQQxFgQUaQuviyjD+rAD2E4aTtSG9bim1RIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAHAsVWrJORhIYN9qX/QKrLMSZ0Rm4tFq7oHVaYAAssTU9QFIpU1WUVdrXspDr365GuDZn E27rCRw1+WRUn2O3MgGPpzNWYjtBNhzTyom0sxImftKHCczkoxnTdGWwIe3q251dQ/EEUQRXFIhf 7GicN8Ttmd34Gf1UaBh4/AVyswH0x+/RxfoNGxw8nHZAQkNOFHrGBKB7RfgeTeY4IUG72LQWOIcl vmN/p0R19ihUqOPWJZjXf2eaXbwNuG+I2iDCezTy7qXCtSkJnskUqtsXKxo2dfnxUjFQ6fRJzUsn xBYNg1zrtBMmtEa88yq8ChKTxsXrh+Mwc7JEcqhai95IfwAAAAAAAA== --Apple-Mail-8--95557856-- --===============1087933588== 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 -------------------------------------------------------------------- --===============1087933588==-- From ipv6-bounces@ietf.org Mon May 09 14:45:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVDGH-0005Ah-Ra; Mon, 09 May 2005 14:45:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVDGF-0005Ac-9o for ipv6@megatron.ietf.org; Mon, 09 May 2005 14:45:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17836 for ; Mon, 9 May 2005 14:45:45 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVDVO-0004kE-LZ for ipv6@ietf.org; Mon, 09 May 2005 15:01:27 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel10.hp.com (Postfix) with ESMTP id 96E55A18 for ; Mon, 9 May 2005 11:45:43 -0700 (PDT) Received: from [127.0.0.1] (pa772625.cup.hp.com [15.13.128.109]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id AAA24076 for ; Tue, 10 May 2005 00:14:02 +0530 (IST) Message-ID: <427FAFD3.4010701@india.hp.com> Date: Mon, 09 May 2005 11:45:39 -0700 From: Arun Thulasi 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: multipart/mixed; boundary="------------030605000706030804040509" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Subject: draft-arunt-ipv6-multicast-filtering-rules-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: arunt@india.hp.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 This is a multi-part message in MIME format. --------------030605000706030804040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------030605000706030804040509 Content-Type: text/plain; name="draft-arunt-ipv6-multicast-filtering-rules-00.txt" Content-Disposition: inline; filename="draft-arunt-ipv6-multicast-filtering-rules-00.txt" Content-Transfer-Encoding: 7bit Network Working Group Arun Thulasi Internet-Draft Hewlett Packard May 2005 IPv6 Multicast Filtering Rules Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3978. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 10, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes requirements and rules for multicast packets to be filtered in IP before sending it to the upper layer protocols like TCP or UDP. Arun Thulasi Expires November 10, 2005 [Page 1] Internet-Draft IPv6 Multicast Filtering Rules May 2005 Table of Contents 1. Introduction............................................ 2 2. Terminologies and Definitions........................... 2 3. Current Behavior........................................ 2 4. Multicast Applications' Behavior ....................... 3 4.1 Synopsis of Multicast Server Behavior................ 3 4.2 Synopsis of Multicast Client Behavior................. 3 5. Multicast Address Types and Recommended Behavior........ 3 5.1 Special Case Addresses............................... 3 5.2 Other Multicast Addresses............................ 3 6. IANA Considerations........................................ 4 7. Security Considerations.................................... 4 References.................................................... 5 Authors' Addresses............................................ 5 Appendix A: A method to allow an implementation to provide both behaviors.................................... 5 Copyright Statement........................................... 6 Intellectual Property Statement............................... 7 Acknowledgements.............................................. 7 1. Introduction Multicasting[MULTICAST] is one of the important functionalities supported by an Internet Protocol. Multicasting allows an application to join any number of given multicast addresses on an interface and be able to receive packets destined for the multicast addresses. In certain cases, Multicasting also allows the application to receive packets destined to a multicast address even if it has not joined the appropriate multicast address. This behavior of Multicasting has been implemented differently across operating systems. This document specifies a set of rules to ensure interoperability across operating systems and would guarantee consistency across implementations. 2. Terminologies and Definitions Upper Layer Protocols (ULP): Upper Layer Protocol refers to a protocol that lies above the Internet Protocol. For example, It could be Transmission Control Protocol [TCP] or User Datagram Protocol [UDP]. Multicast Address (MA): A Multicast Address, unless and otherwise explicitly specified, refers to a Multicast Address in [IPv6]. It also refers to the Multicast Address Group that an application might join. 3. Current Behavior The current behavior is implementation specific. While certain implementations allow the application to receive packets destined to the All Nodes Address and other appropriate addresses even if they have not explicitly joined the address, certain other implementations do not deliver such messages. Arun Thulasi Expires November 10, 2005 [Page 2] Internet-Draft IPv6 Multicast Filtering Rules May 2005 This document aims at having interoperability when applications are ported across different implementations. This behavior of multicast filtering is optional, and the implementation might device its own way of intimating the application. However, the default behavior would be to perform no filtering in IP based on the multicast listening groups that the application is part of. 4. Multicast Applications' Behavior 4.1 Synopsis of Multicast Server Behavior The multicast server sends packets addressed to the appropriate MA. The destination address field in the IP header would be the MA and the port would be set to the foreign port in the remote host. The multicast server would expect the packet to reach the nodes that are associated with this multicast group and listening on the port. 4.2 Synopsis of Multicast Client Behavior A Multicast Client would join a MA Group using an implementation specific mechanism. It must bind either to the MA or to the unspecified address AND a given port. A client must join the multicast address group in order to ensure receiving packets destined to that multicast group address. A Multicast Client would leave a Multicast Address Group using an implementation specific mechanism. 5. Multicast Address Types and Recommended Behavior 5.1 Special Addresses In multicasting, certain addresses are designated as special addresses which every application is expected to listen on. All IPv6 nodes are expected to listen on the All Nodes Multicast Address of ff02::1 and the Solicited Node Multicast Address which is computed as function of the IPv6 Address [IPv6 Multi]. If a machine is brought up as a router, it would be expected to listen on the All Routers Multicast Address of ff02::2 as well [IPv6 Multi]. Any Application should receive packets destined to the aforesaid multicast addresses even if they have not explicitly joined those Address Groups. Applications should continue to receive packets even if they had explicitly joined and left the aforesaid groups. 5.2 Other Multicast Addresses Any other address that is not a special address is considered to be an ordinary multicast address. Arun Thulasi Expires November 10, 2005 [Page 3] Internet-Draft IPv6 Multicast Filtering Rules May 2005 When the Internet Protocol receives a packet destined for a MA, it must check for listeners on the port, bound to either the MA specified in the destination field of the IP header or the Unspecified Address AND the port. If such an entry is available, IP SHOULD deliver it to the ULP. An Application MAY receive packets destined to any of the other multicast addresses if, and only if, the application is bound to either the MA itself or to the UA, and is bound to the port that matches the destination port in the IP Packet. An Application MUST NOT receive packets destined to any of the ordinary multicast addresses if it is not bound to that specific address or the Unspecified Address OR if it is not bound to the appropriate port. The IP MAY implement another level of filtering to determine if the application has registered itself to the multicast group by joining the MA using an implementation specific mechanism. This behavior is optional and IP may implement this feature based on implementation specifications. However, the default behavior would be that an application MAY receive a packet even when it has not joined the group explicitly if it satisfies any of the conditions mentioned above. An application SHALL NOT expect to receive packets destined to the port by merely binding to unspecified address/port. To ensure that an application always receives packets destined to a certain multicast address, the application would have to explicitly join the multicast group. This concept of optional filtering by IP arises only when the packet is delivered to IP by the lower layer. If the lower-layer, for any reason, does not send the packet upstream to IP, the requirement for optional filtering by IP does not arise. 6. IANA Considerations There are no IANA considerations for this document. 7. Security Considerations The behavior specified in this document does not have any known security issue as of now since - The behavior suggested here is optional and not mandated. However it is recommended that an implementation provide a method of informing the application about its behavior to facilitate interoperability. - The packet may be delivered to an application only if it has bound to the appropriate address/port combination AND if the packet has the same port number in the destination field of the IP header. Hence, to shut out unwanted packets, the application could bind Arun Thulasi Expires November 10, 2005 [Page 4] Internet-Draft IPv6 Multicast Filtering Rules May 2005 itself to the MA itself. References IP Refers to [IPv6], unless specifically mentioned otherwise. [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 [TCP] Postel, J., "Transmission Control Protocol", STD 5, RFC 793, September 1981. [UDP] Postel, J., "User Datagram Protocol", STD 5, RFC 793, August 1980. [IPv6-MULTI] Deering, S., Hinden, R., "IPv6 Multicast Address Assignments", RFC 2375, December 1998 [IPv6-ADDR] Deering, S., Hinden, R., "IP Version 6 Addressing Architecture", Work in Progress, February 2005 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC2119, March 1997. [MULTICAST] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989. Authors' Addresses Comments are solicited and should be addressed to the working group's mailing list at ipv6@ietf.org and/or the author(s). Arun Thulasi Hewlett-Packard, 29, Cunningham Road Bangalore - 560052 India. arun_thulasi@hp.com Appendix A: A method to allow an implementation to provide both behaviors One way to provide this behavior is using a kernel tunable and make multicast filtering in IP a system wide behavior. When multicast filtering is enabled, the implementation could intimate the calling application using an appropriate error message that it has not been sent a packet which it should have gotten otherwise. Arun Thulasi Expires November 10, 2005 [Page 5] Internet-Draft IPv6 Multicast Filtering Rules May 2005 Another way that an implementation could provide both the behaviors would be by providing an appropriate socket option. This option would make Multicast Filtering in IP a socket/application specific behavior. When an application wants to enable multicast filtering in IP, it would send the appropriate socket option to enable it in IP. Once the application is done, it could unset the option using a similar socket option. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Arun Thulasi Expires November 10, 2005 [Page 6] Internet-Draft IPv6 Multicast Filtering Rules May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Arun Thulasi Expires November 10, 2005 [Page 7] --------------030605000706030804040509 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 -------------------------------------------------------------------- --------------030605000706030804040509-- From ipv6-bounces@ietf.org Mon May 09 14:54:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVDOT-00076W-L2; Mon, 09 May 2005 14:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVDOP-00075d-SE for ipv6@megatron.ietf.org; Mon, 09 May 2005 14:54:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18699 for ; Mon, 9 May 2005 14:54:12 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVDdZ-000532-AE for ipv6@ietf.org; Mon, 09 May 2005 15:09:54 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel11.hp.com (Postfix) with ESMTP id C14645026 for ; Mon, 9 May 2005 11:54:08 -0700 (PDT) Received: from [127.0.0.1] (pa772625.cup.hp.com [15.13.128.109]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id AAA26423 for ; Tue, 10 May 2005 00:22:28 +0530 (IST) Message-ID: <427FB1CC.3080604@india.hp.com> Date: Mon, 09 May 2005 11:54:04 -0700 From: Arun Thulasi User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org References: <427FAFD3.4010701@india.hp.com> In-Reply-To: <427FAFD3.4010701@india.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b Content-Transfer-Encoding: 7bit Subject: Re: draft-arunt-ipv6-multicast-filtering-rules-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: arunt@india.hp.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 whoops .. wrong alias ..apologies to all the folks .. arun thulasi > >------------------------------------------------------------------------ > > >Network Working Group Arun Thulasi >Internet-Draft Hewlett Packard > May 2005 > > > > IPv6 Multicast Filtering Rules > > > > >Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of section 3 of RFC 3978. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she becomes aware will be disclosed, in accordance with > Section 6 of BCP 79. This document may not be modified, and > derivative works of it may not be created, except to publish it as > an RFC and to translate it into languages other than English. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on November 10, 2005. > > >Copyright Notice > > Copyright (C) The Internet Society (2005). All Rights Reserved. > > >Abstract > > This document describes requirements and rules for multicast > packets to be filtered in IP before sending it to the upper layer > protocols like TCP or UDP. > > > > > >Arun Thulasi Expires November 10, 2005 [Page 1] > >Internet-Draft IPv6 Multicast Filtering Rules May 2005 > >Table of Contents > > 1. Introduction............................................ 2 > 2. Terminologies and Definitions........................... 2 > 3. Current Behavior........................................ 2 > 4. Multicast Applications' Behavior ....................... 3 > 4.1 Synopsis of Multicast Server Behavior................ 3 > 4.2 Synopsis of Multicast Client Behavior................. 3 > 5. Multicast Address Types and Recommended Behavior........ 3 > 5.1 Special Case Addresses............................... 3 > 5.2 Other Multicast Addresses............................ 3 > 6. IANA Considerations........................................ 4 > 7. Security Considerations.................................... 4 > > References.................................................... 5 > Authors' Addresses............................................ 5 > Appendix A: A method to allow an implementation to provide > both behaviors.................................... 5 > Copyright Statement........................................... 6 > Intellectual Property Statement............................... 7 > Acknowledgements.............................................. 7 > >1. Introduction > > Multicasting[MULTICAST] is one of the important functionalities > supported by an Internet Protocol. Multicasting allows an > application to join any number of given multicast addresses on an > interface and be able to receive packets destined for the multicast > addresses. In certain cases, Multicasting also allows the application > to receive packets destined to a multicast address even if it has not > joined the appropriate multicast address. This behavior of > Multicasting has been implemented differently across operating > systems. This document specifies a set of rules to ensure > interoperability across operating systems and would guarantee > consistency across implementations. > >2. Terminologies and Definitions > > Upper Layer Protocols (ULP): Upper Layer Protocol refers to a > protocol that lies above the Internet Protocol. For example, > It could be Transmission Control Protocol [TCP] or User > Datagram Protocol [UDP]. > > Multicast Address (MA): A Multicast Address, unless and otherwise > explicitly specified, refers to a Multicast Address in > [IPv6]. It also refers to the Multicast Address Group that an > application might join. > >3. Current Behavior > > The current behavior is implementation specific. While certain > implementations allow the application to receive packets destined to > the All Nodes Address and other appropriate addresses even if > they have not explicitly joined the address, certain other > implementations do not deliver such messages. > > >Arun Thulasi Expires November 10, 2005 [Page 2] > >Internet-Draft IPv6 Multicast Filtering Rules May 2005 > > > This document aims at having interoperability when applications are > ported across different implementations. This behavior of multicast > filtering is optional, and the implementation might device its own > way of intimating the application. However, the default behavior > would be to perform no filtering in IP based on the multicast > listening groups that the application is part of. > > >4. Multicast Applications' Behavior > > >4.1 Synopsis of Multicast Server Behavior > > The multicast server sends packets addressed to the appropriate > MA. The destination address field in the IP header would be the MA > and the port would be set to the foreign port in the remote host. > The multicast server would expect the packet to reach the nodes > that are associated with this multicast group and listening on > the port. > >4.2 Synopsis of Multicast Client Behavior > > A Multicast Client would join a MA Group using an implementation > specific mechanism. It must bind either to the MA or to the > unspecified address AND a given port. A client must join the > multicast address group in order to ensure receiving packets > destined to that multicast group address. > > A Multicast Client would leave a Multicast Address Group using an > implementation specific mechanism. > > >5. Multicast Address Types and Recommended Behavior > >5.1 Special Addresses > > In multicasting, certain addresses are designated as special > addresses which every application is expected to listen on. All > IPv6 nodes are expected to listen on the All Nodes Multicast > Address of ff02::1 and the Solicited Node Multicast Address which is > computed as function of the IPv6 Address [IPv6 Multi]. If a machine > is brought up as a router, it would be expected to listen on the > All Routers Multicast Address of ff02::2 as well [IPv6 Multi]. > > Any Application should receive packets destined to the aforesaid > multicast addresses even if they have not explicitly joined those > Address Groups. Applications should continue to receive packets even > if they had explicitly joined and left the aforesaid groups. > > >5.2 Other Multicast Addresses > > Any other address that is not a special address is considered to be > an ordinary multicast address. > > >Arun Thulasi Expires November 10, 2005 [Page 3] > >Internet-Draft IPv6 Multicast Filtering Rules May 2005 > > > When the Internet Protocol receives a packet destined for a MA, it > must check for listeners on the port, bound to either the MA > specified in the destination field of the IP header or the > Unspecified Address AND the port. If such an entry is available, > IP SHOULD deliver it to the ULP. > > An Application MAY receive packets destined to any of the other > multicast addresses if, and only if, the application is bound to > either the MA itself or to the UA, and is bound to the port that > matches the destination port in the IP Packet. > > An Application MUST NOT receive packets destined to any of the > ordinary multicast addresses if it is not bound to that specific > address or the Unspecified Address OR if it is not bound to the > appropriate port. > > The IP MAY implement another level of filtering to determine if the > application has registered itself to the multicast group by joining > the MA using an implementation specific mechanism. This behavior is > optional and IP may implement this feature based on implementation > specifications. However, the default behavior would be that > an application MAY receive a packet even when it has not joined the > group explicitly if it satisfies any of the conditions mentioned > above. > > An application SHALL NOT expect to receive packets destined to the > port by merely binding to unspecified address/port. To ensure that an > application always receives packets destined to a certain > multicast address, the application would have to explicitly join > the multicast group. > > This concept of optional filtering by IP arises only when the packet > is delivered to IP by the lower layer. If the lower-layer, for any > reason, does not send the packet upstream to IP, the requirement for > optional filtering by IP does not arise. > >6. IANA Considerations > > There are no IANA considerations for this document. > >7. Security Considerations > > The behavior specified in this document does not have any known > security issue as of now since > > - The behavior suggested here is optional and not mandated. However > it is recommended that an implementation provide a method of > informing the application about its behavior to facilitate > interoperability. > > - The packet may be delivered to an application only if it has > bound to the appropriate address/port combination AND if the packet > has the same port number in the destination field of the IP header. > Hence, to shut out unwanted packets, the application could bind > > >Arun Thulasi Expires November 10, 2005 [Page 4] > >Internet-Draft IPv6 Multicast Filtering Rules May 2005 > > itself to the MA itself. > > > >References > > IP Refers to [IPv6], unless specifically mentioned > otherwise. > > [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, > September 1981. > > [IPv6] Deering, S., Hinden, R., "Internet Protocol, Version 6 > (IPv6) Specification", RFC 2460, December 1998 > > [TCP] Postel, J., "Transmission Control Protocol", STD 5, > RFC 793, September 1981. > > [UDP] Postel, J., "User Datagram Protocol", STD 5, RFC 793, > August 1980. > > [IPv6-MULTI] Deering, S., Hinden, R., "IPv6 Multicast Address > Assignments", RFC 2375, December 1998 > > [IPv6-ADDR] Deering, S., Hinden, R., "IP Version 6 Addressing > Architecture", Work in Progress, February 2005 > > [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP14, RFC2119, March 1997. > > [MULTICAST] Deering, S., "Host Extensions for IP Multicasting", > STD 5, RFC 1112, Stanford University, August 1989. > > >Authors' Addresses > > Comments are solicited and should be addressed to the working > group's mailing list at ipv6@ietf.org and/or the author(s). > > Arun Thulasi > Hewlett-Packard, > 29, Cunningham Road > Bangalore - 560052 > India. > arun_thulasi@hp.com > > >Appendix A: A method to allow an implementation to provide both > behaviors > > One way to provide this behavior is using a kernel tunable and > make multicast filtering in IP a system wide behavior. When > multicast filtering is enabled, the implementation could intimate > the calling application using an appropriate error message that > it has not been sent a packet which it should have gotten otherwise. > > >Arun Thulasi Expires November 10, 2005 [Page 5] > >Internet-Draft IPv6 Multicast Filtering Rules May 2005 > > > Another way that an implementation could provide both the behaviors > would be by providing an appropriate socket option. This option > would make Multicast Filtering in IP a socket/application specific > behavior. When an application wants to enable multicast filtering > in IP, it would send the appropriate socket option to enable it > in IP. Once the application is done, it could unset the option > using a similar socket option. > >Copyright Statement > > Copyright (C) The Internet Society (2005). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Arun Thulasi Expires November 10, 2005 [Page 6] > >Internet-Draft IPv6 Multicast Filtering Rules May 2005 > >Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > >Acknowledgments > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Arun Thulasi Expires November 10, 2005 [Page 7] > > > >------------------------------------------------------------------------ > >-------------------------------------------------------------------- >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 May 10 09:19:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVUe5-0005nu-Qz; Tue, 10 May 2005 09:19:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVUe3-0005nk-BZ for ipv6@megatron.ietf.org; Tue, 10 May 2005 09:19:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24839 for ; Tue, 10 May 2005 09:19:29 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVUtM-0007nB-AM for ipv6@ietf.org; Tue, 10 May 2005 09:35:21 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 363993 for ipv6@ietf.org; Tue, 10 May 2005 09:15:21 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 10 May 2005 09:19:14 -0400 To: ipv6@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-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 Hi All, I have a few AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 that I would like to have resolved before I send this document to IETF LC. I've included those comments below. Brian and Bob, the tracker indicates that this document is intended for publication as a Draft Standard, however RFC 3041 is currently at PS, and this document seems to contain some changes to the specification that would impact implementations (such as the requirement to perform DAD on all generated addresses). Is the tracker state correct? If so, what is the rationale for publishing this document at DS? Thanks, Margaret >> I think that sometihng went wrong with the structure of this document: Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 1.2 Conventions used in this document . . . . . . . . . . . . 5 >> Why is the RFC 2119 section inside the problem statement? 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9 >> Is section 2 supposed to be part of the problem statement? 3. Protocol Description The goal of this section is to define procedures that: 1. Do not result in any changes to the basic behavior of addresses generated via stateless address autoconfiguration [ADDRCONF]. 2. Create additional global scope addresses based on a random interface identifier for use with global scope addresses. >> What is meant by "for use with global addresses"? is this intended to be a restriction on how/when privacy addresses can be used? 3.1 Assumptions The following algorithm assumes that each interface maintains an associated randomized interface identifier. When temporary addresses are generated, the current value of the associated randomized interface identifier is used. The actual value of the identifier changes over time as described below, but the same identifier can be used to generate more than one temporary address. The algorithm also assumes that for a given temporary address, an implementation can determine the prefix from which it was generated. When a temporary address is deprecated, a new temporary address is generated. The specific valid and preferred lifetimes for the new address are dependent on the corresponding lifetime values set for the prefix from which it was generated. >> These two paragraphs are confusing to me. The node maintains a random IID from which multiple addresses can be generated of the form , right? These addresses will become deprecated when their lifetime expires, and new addresses will be generated. The implementation keeps track of what prefix was used to generate the addres and generates a new address for that prefix, right? Does it also need to generate a new random IID when this happens? In other words, is there anything in this mechanism that prevents generating the same privacy address again on the same interface using the same prefix and the same random IID (if it hasn't expired yet)? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 11 01:01:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjLS-0005dB-Ub; Wed, 11 May 2005 01:01:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjLM-0005cl-Pf for ipv6@megatron.ietf.org; Wed, 11 May 2005 01:01:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23924 for ; Wed, 11 May 2005 01:01:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVjan-0006lt-Cu for ipv6@ietf.org; Wed, 11 May 2005 01:17:11 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVjLI-000Hyg-QW; Wed, 11 May 2005 05:01:08 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #921 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Wed, 11 May 2005 05:01:08 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org, housley@vigilsec.com Subject: [psg.com #921] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.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 We seem to reach a consensus on this issue with the following resolution: Change the references to IPsec Authentication Header to references to SEND [RFC3971], and categorize the new reference as informative. For relevant discussion at the wg list, see the list thread starting at: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04824.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 11 01:01:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjLU-0005dc-Hd; Wed, 11 May 2005 01:01:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjLM-0005ck-LW for ipv6@megatron.ietf.org; Wed, 11 May 2005 01:01:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23925 for ; Wed, 11 May 2005 01:01:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVjan-0006lu-EO for ipv6@ietf.org; Wed, 11 May 2005 01:17:11 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVjLI-000Hye-GA; Wed, 11 May 2005 05:01:08 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #921 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Wed, 11 May 2005 05:01:08 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org, housley@vigilsec.com Subject: [psg.com #921] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.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 We seem to reach a consensus on this issue with the following resolution: Change the references to IPsec Authentication Header to references to SEND [RFC3971], and categorize the new reference as informative. For relevant discussion at the wg list, see the list thread starting at: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04824.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 11 01:38:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjvR-0004Pg-6F; Wed, 11 May 2005 01:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjvO-0004PX-PO for ipv6@megatron.ietf.org; Wed, 11 May 2005 01:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26538 for ; Wed, 11 May 2005 01:38:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVkAr-00008I-8r for ipv6@ietf.org; Wed, 11 May 2005 01:54:25 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVjvN-000Khk-3L; Wed, 11 May 2005 05:38:25 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #921 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Wed, 11 May 2005 05:38:25 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org, housley@vigilsec.com Subject: [psg.com #921] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.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 We seem to reach a consensus on this issue with the following resolution: Change the references to IPsec Authentication Header to references to SEND [RFC3971], and categorize the new reference as informative. For relevant discussion at the wg list, see the list thread starting at: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04824.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 11 01:38:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjvS-0004QK-SV; Wed, 11 May 2005 01:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVjvO-0004PW-Im for ipv6@megatron.ietf.org; Wed, 11 May 2005 01:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26537 for ; Wed, 11 May 2005 01:38:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVkAr-00008G-8n for ipv6@ietf.org; Wed, 11 May 2005 01:54:25 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVjvM-000Khg-PS; Wed, 11 May 2005 05:38:24 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #921 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Wed, 11 May 2005 05:38:24 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipv6@ietf.org, housley@vigilsec.com Subject: [psg.com #921] reference to SEND from 2462bis X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.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 We seem to reach a consensus on this issue with the following resolution: Change the references to IPsec Authentication Header to references to SEND [RFC3971], and categorize the new reference as informative. For relevant discussion at the wg list, see the list thread starting at: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04824.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 11 01: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 1DVkDN-0000cf-BV; Wed, 11 May 2005 01:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkDK-0000a8-G8 for ipv6@megatron.ietf.org; Wed, 11 May 2005 01:56:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28184 for ; Wed, 11 May 2005 01:56:57 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVkSk-00017B-T4 for ipv6@ietf.org; Wed, 11 May 2005 02:12:57 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9DAA215218; Wed, 11 May 2005 14:58:34 +0900 (JST) Date: Wed, 11 May 2005 14:57:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko In-Reply-To: <4271E1DE.1040805@kolumbus.fi> References: <4270AEE3.2010202@kolumbus.fi> <4271E1DE.1040805@kolumbus.fi> 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, mankin@psg.com Subject: Re: [rfc2462bis] config consistency vs secure ND/DHCPv6 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, 29 Apr 2005 10:27:26 +0300, >>>>> Jari Arkko said: > Ok. Didn't realize this. >> So, it may make more sense just to provide related consideration (but >> not a requirement for implementations), e.g.: [snip] >> What do you (and others, Allison in particular) think? Last call: I'd still seek confirmation on the intent of the comment and the proposed resolution from Allison, but since the list has been silence on this issue for about two weeks, I'm going to close this issue with the proposed text soon. 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 Wed May 11 02:04:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkKq-0002Sy-FB; Wed, 11 May 2005 02:04:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkKo-0002St-5d for ipv6@megatron.ietf.org; Wed, 11 May 2005 02:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03396 for ; Wed, 11 May 2005 02:04:40 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVkaD-0001XP-G8 for ipv6@ietf.org; Wed, 11 May 2005 02:20:41 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A0AC215210; Wed, 11 May 2005 15:06:25 +0900 (JST) Date: Wed, 11 May 2005 15:05:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org, margaret@thingmagic.com, mankin@psg.com 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: Re: (retry) implementation report for rfc2462bis 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, 26 Apr 2005 20:06:53 +0900, >>>>> JINMEI Tatuya said: > As far as I know there has been no response at the list on this subject: > http://www.ietf.org/mail-archive/web/ipv6/current/msg04465.html > so I'm going to give it a second try, based on the relevant discussion > at the Minneapolis meeting. Hmm...I still keep failing to get any feedback on this issue, and I don't know how to move on. Assuming we've reached a consensus about the "config consistency vs secure ND/DHCPv6" issue (see the separate thread), all the IESG comments except this one are now resolved. And, since this issue may not require a change of the document per se (i.e., it may be a procedural comment, not one on the documentation itself), my next step would be just to submit a new version of the document with the proposed (and agreed) changes for the reset of the comments and see what will happen. If I miss something fundamental, please point it out ASAP. Thanks, 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 Wed May 11 06:07:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVo88-00042x-Q0; Wed, 11 May 2005 06:07:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVo86-00042p-N5; Wed, 11 May 2005 06:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18669; Wed, 11 May 2005 06:07:47 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVoNa-00054V-MW; Wed, 11 May 2005 06:23:52 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IGB008KJLNXIW@szxga02-in.huawei.com>; Wed, 11 May 2005 18:11:57 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IGB005NELNXTW@szxga02-in.huawei.com>; Wed, 11 May 2005 18:11:57 +0800 (CST) Received: from sachin1734 ([10.18.4.66]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IGB00D1WLNRG1@szxml02-in.huawei.com>; Wed, 11 May 2005 18:11:53 +0800 (CST) Date: Wed, 11 May 2005 03:07:39 -0700 From: Sachin In-reply-to: <000001c5523e$1ab581c0$b504120a@china.huawei.com> To: deering@cisco.com, ipv6@ietf.org, mip6@ietf.org, Majordomo@anarg.jp Message-id: <000001c55611$44a82470$4204120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 08156cf414e01129f6a937203576bf20 Cc: Subject: Issues Related to Mobile Anycast Address X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sachind@huawei.com List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0693419143==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0693419143== Content-type: multipart/alternative; boundary="Boundary_(ID_6RnR6Xgv+JueIBaBR8h4fg)" This is a multi-part message in MIME format. --Boundary_(ID_6RnR6Xgv+JueIBaBR8h4fg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, Following are two issues related to Anycast can some one plz clarify on same First as raised by Keshava that anycast address corresponding to unicast global address becoming multicast addresses, RFC has not put any specific condition for prefix length, so as per RFC 3513 for the following unassigned global addresses with prefix length less then 8 the corresponding mip6 anycast address will be multicast Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unassigned 1111 110 1/128 Unassigned 1111 1110 0 1/512 "RFC 3513 Allocation Prefix Fraction of (binary) Address Space ----------------------------------- -------- ------------- Unassigned (see Note 1 below) 0000 0000 1/256 Unassigned 0000 0001 1/256 Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] Unassigned 0000 01 1/64 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Global Unicast 001 1/8 [RFC2374] Unassigned 010 1/8 Unassigned 011 1/8 Unassigned 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8 Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unassigned 1111 110 1/128 Unassigned 1111 1110 0 1/512 Link-Local Unicast Addresses 1111 1110 10 1/1024 Site-Local Unicast Addresses 1111 1110 11 1/1024 Multicast Addresses 1111 1111 1/256 " 2 The other issue is that for different prefix anycast address formed can be same for example ipv6 address DDDD::FDF0:0:0:2/76 ipv6 address DDDD::2/64 ipv6 address DDDD::FD00:0:0:2/72 MIP6 Anycast address DDDD::FDFF:FFFF:FFFF:FFFE Mobile nodes from these three different subnet; will generate same mip6 anycast address. So their home agent discovery reply may not be from correct home network Kindly comment on this Regards Sachin -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Keshava Ayanur Sent: Friday, May 06, 2005 6:19 AM To: ipv6@ietf.org; mip6@ietf.org Subject: [Mip6] Anycast Address becoming Multicast address .... Hi, When the global unicast address with prefix 2 (ex: DADA::100/2) is given for the interface, Mobile IPV6 anycast address corresponding to this should be as below( RFC 2526). Format of Reserved Subnet Anycast Addresses: | n bits | 121-n bits | 7 bits | +---------------------------------+-----------.-------+------------ + | subnet prefix | 111..111111 | anycast ID | +---------------------------------+------------------+----------- -+ | interface identifier field | So MIP6 any cast address corresponding to this global unicast address (DADA::100/2) will be FFFF:FFFF:FFFF:FFFF:FFFE as the subnet prefix will 11 (prefix length is 2 only) This FFFF:FFFF:FFFF:FFFF:FFFE is a multicast address. But as per RFC 3513 IPv6 Addressing Architecture, "Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats" Can someone clarify this in-discrepancy? Regards, keshava --Boundary_(ID_6RnR6Xgv+JueIBaBR8h4fg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

 

Following are two issues related to Anycast can some one plz clarify on same

 

First as raised by Keshava that anycast address corresponding to unicast global address becoming multicast addresses, RFC has not put any specific condition for prefix length, so as per RFC 3513 for the following unassigned global addresses with prefix length less then 8 the corresponding mip6 anycast address will be multicast

   Unassigned                            1110           1/16

   Unassigned                            1111 0         1/32

   Unassigned                            1111 10        1/64

   Unassigned                            1111 110       1/128

   Unassigned                            1111 1110 0    1/512

 

“RFC 3513

 

Allocation                            Prefix         Fraction of

                                         (binary)       Address Space

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

   Unassigned (see Note 1 below)         0000 0000      1/256

   Unassigned                            0000 0001      1/256

   Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]

   Unassigned                            0000 01        1/64

   Unassigned                            0000 1         1/32

   Unassigned                            0001           1/16

   Global Unicast                        001            1/8   [RFC2374]

   Unassigned                            010            1/8

   Unassigned                            011            1/8

   Unassigned                            100            1/8

   Unassigned                            101            1/8

   Unassigned                            110            1/8

   Unassigned                            1110           1/16

   Unassigned                            1111 0         1/32

   Unassigned                            1111 10        1/64

   Unassigned                            1111 110       1/128

   Unassigned                            1111 1110 0    1/512

   Link-Local Unicast Addresses          1111 1110 10   1/1024

   Site-Local Unicast Addresses          1111 1110 11   1/1024

   Multicast Addresses                   1111 1111      1/256

 

“

2 The other issue is that for different prefix anycast address formed can be same for example

 

ipv6 address DDDD::FDF0:0:0:2/76

ipv6 address DDDD::2/64     

ipv6 address DDDD::FD00:0:0:2/72

 

MIP6 Anycast address

 

DDDD::FDFF:FFFF:FFFF:FFFE

 

 

Mobile nodes from these three different subnet; will generate same mip6 anycast address. So their home agent discovery reply may not be from correct home network

 

Kindly comment on this

 

Regards

Sachin

 

-----Original Message-----
From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Keshava Ayanur
Sent: Friday, May 06, 2005 6:19 AM
To: ipv6@ietf.org; mip6@ietf.org
Subject: [Mip6] Anycast Address becoming Multicast address ....

 

Hi,

When the global unicast address with prefix 2 (ex: DADA::100/2) is given for the interface, Mobile IPV6 anycast address corresponding to this should be as below( RFC 2526).

 

 Format of Reserved Subnet Anycast Addresses:

 

   |              n bits            |    121-n bits  |   7 bits   |

  +---------------------------------+-----------.-------+------------ +

   |      subnet prefix         | 111..111111 | anycast ID |

  +---------------------------------+------------------+----------- -+

                                      |   interface identifier field  |

 

So MIP6 any cast address corresponding to this global unicast address (DADA::100/2) will be

FFFF:FFFF:FFFF:FFFF:FFFE as  the subnet prefix will 11 (prefix length is 2 only)

 

This  FFFF:FFFF:FFFF:FFFF:FFFE is a multicast address.

           

 

But as per RFC 3513 IPv6 Addressing Architecture,

 “Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats”

 

            Can someone clarify this in-discrepancy?

 

 

Regards,

keshava

           

--Boundary_(ID_6RnR6Xgv+JueIBaBR8h4fg)-- --===============0693419143== 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 -------------------------------------------------------------------- --===============0693419143==-- From ipv6-bounces@ietf.org Wed May 11 10:17:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVs1k-0002r8-1j; Wed, 11 May 2005 10:17:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVs1h-0002r3-EV for ipv6@megatron.ietf.org; Wed, 11 May 2005 10:17:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07562 for ; Wed, 11 May 2005 10:17:27 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVsHC-00016M-RU for ipv6@ietf.org; Wed, 11 May 2005 10:33:32 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j4BEHFOA031823; Wed, 11 May 2005 09:17:15 -0500 Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KTXN3YC9; Wed, 11 May 2005 09:17:13 -0500 Received: from [142.133.72.115] ([142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j4BEH6Xq003319; Wed, 11 May 2005 10:17:10 -0400 (EDT) Date: Wed, 11 May 2005 10:15:23 -0400 (EDT) X-Sybari-Trust: 506abd56 0ad8d99f 09f00c87 00000139 From: Suresh Krishnan X-X-Sender: suresh@localhost.localdomain To: Margaret Wasserman In-Reply-To: Message-ID: <8DA338857B4F404282EE2088005079EA02B1C05E@eammlex037-nb.lmc.ericsson.se> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ipv6@ietf.org Subject: Re: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 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 Margaret, Thanks for the comments. Please see my replies inline. Thanks Suresh On Tue, 10 May 2005, Margaret Wasserman wrote: >>> I think that sometihng went wrong with the structure of this document: > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 > 1.2 Conventions used in this document . . . . . . . . . . . . 5 > >>> Why is the RFC 2119 section inside the problem statement? It is just another sub section under introduction to the document and is not under the problem statement. I can move this to a separate section if you feel strongly about this. > > 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6 > 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7 > 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8 > 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9 > >>> Is section 2 supposed to be part of the problem statement? The problem statement is a concise description of the threat model we are defending against. Section 2 is a much more detailed study of the problems involved. The problem statement was created to provide the reader with some context as to why the document is needed. So the problem statement is a summary of sorts of section 2. > > > 3. Protocol Description > > The goal of this section is to define procedures that: > > 1. Do not result in any changes to the basic behavior of addresses > generated via stateless address autoconfiguration [ADDRCONF]. > 2. Create additional global scope addresses based on a random > interface identifier for use with global scope addresses. > >>> What is meant by "for use with global addresses"? is this intended > to be a restriction on how/when privacy addresses can be used? This is not an intended restriction. I can reword it to read "2. Create additional addresses based on a random interface identifier for the purpose of initiating outgoing sessions" instead of "2. Create additional global scope addresses based on a random interface identifier for use with global scope addresses.Such addresses would be used to initiate outgoing sessions." Does that sound OK? > > 3.1 Assumptions > > The following algorithm assumes that each interface maintains an > associated randomized interface identifier. When temporary addresses > are generated, the current value of the associated randomized > interface identifier is used. The actual value of the identifier > changes over time as described below, but the same identifier can be > used to generate more than one temporary address. > > The algorithm also assumes that for a given temporary address, an > implementation can determine the prefix from which it was generated. > When a temporary address is deprecated, a new temporary address is > generated. The specific valid and preferred lifetimes for the new > address are dependent on the corresponding lifetime values set for > the prefix from which it was generated. > >>> These two paragraphs are confusing to me. The node maintains a > random IID from which multiple addresses can be generated of the > form , right? These addresses will become deprecated > when their lifetime expires, and new addresses will be generated. > The implementation keeps track of what prefix was used to generate > the addres and generates a new address for that prefix, right? > Does it also need to generate a new random IID when this happens? > In other words, is there anything in this mechanism that prevents > generating the same privacy address again on the same interface > using the same prefix and the same random IID (if it hasn't expired > yet)? The mechanism certainly allows this behavior but it kind of defeats the purpose(to not have a stable interface identifier). The requirement to change the random interface identifier is a SHOULD and is described in section 3.5 " Nodes following this specification SHOULD generate new temporary addresses on a periodic basis. This can be achieved automatically by generating a new randomized interface identifier at least once every (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units." If you think this is should be a stronger requirement I can change it to a MUST at the cost of breaking backward compatibility. Let me know what you prefer. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 12 06:39:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWB6E-0008TX-Tn; Thu, 12 May 2005 06:39:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWB6C-0008TN-D4 for ipv6@megatron.ietf.org; Thu, 12 May 2005 06:39:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13003 for ; Thu, 12 May 2005 06:39:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWBLu-00061h-7K for ipv6@ietf.org; Thu, 12 May 2005 06:55:38 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWB68-000Iz9-5e; Thu, 12 May 2005 10:39:20 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #925 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Thu, 12 May 2005 10:39:20 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org, mankin@psg.com Subject: [psg.com #925] config consistency vs secure ND/DHCPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.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 > Discuss comment from Allison Mankin: > > Was there an analysis of the configuration consistency rule > (section 5.6) of accepting the most recent information, while > trying to secure both DHCPv6 and ND/addrconf (SEND)? We seem to reach a consensus on this issue through a discussion at the wg list. See the thread starting at: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04823.html This ticket is closed with the proposed change, which will appear in the next version of the document. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 12 06:39:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWB6J-0008UV-Si; Thu, 12 May 2005 06:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWB6I-0008UP-E5 for ipv6@megatron.ietf.org; Thu, 12 May 2005 06:39:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13007 for ; Thu, 12 May 2005 06:39:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWBM0-000621-FN for ipv6@ietf.org; Thu, 12 May 2005 06:55:44 -0400 Received: from www by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWB68-000IzK-HW; Thu, 12 May 2005 10:39:20 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.66 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #925 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ipv6-2462bis@rt.psg.com Date: Thu, 12 May 2005 10:39:20 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org, mankin@psg.com Subject: [psg.com #925] config consistency vs secure ND/DHCPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ipv6-2462bis@rt.psg.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 > Discuss comment from Allison Mankin: > > Was there an analysis of the configuration consistency rule > (section 5.6) of accepting the most recent information, while > trying to secure both DHCPv6 and ND/addrconf (SEND)? We seem to reach a consensus on this issue through a discussion at the wg list. See the thread starting at: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04823.html This ticket is closed with the proposed change, which will appear in the next version of the document. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 12 12:52:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGvO-0000sU-Jp; Thu, 12 May 2005 12:52:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWGvM-0000sP-JR for ipv6@megatron.ietf.org; Thu, 12 May 2005 12:52:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10817 for ; Thu, 12 May 2005 12:52:33 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWHB7-0006im-Ie for ipv6@ietf.org; Thu, 12 May 2005 13:08:54 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4CGonmD564714 for ; Thu, 12 May 2005 12:51:16 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4CGonck359112 for ; Thu, 12 May 2005 10:50:49 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4CGonkF026420 for ; Thu, 12 May 2005 10:50:49 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4CGondd026401; Thu, 12 May 2005 10:50:49 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4CGoktQ015861; Thu, 12 May 2005 12:50:48 -0400 Message-Id: <200505121650.j4CGoktQ015861@rotala.raleigh.ibm.com> To: Margaret Wasserman Date: Thu, 12 May 2005 12:50:46 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipv6@ietf.org Subject: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 know this is late, but better late than never... Overall, the document is good, but I think that the document would benefit from slight tweaking w.r.t. to multicast. I.e., I assume that an "addressing architecture" should be complete and at a minimum offer pointers to the relevant pieces. I don't think it quite does that in the case of multicast. > 2.7 Multicast Addresses This section only mentions the T flag, and not the P flag. That doesnt seem right, since the P flag is clearly in use now and not "0". Was there a concern about a possible normative reference? I don't think there needs to be. Suggestion: Old: > +-+-+-+-+ > flgs is a set of 4 flags: |0|0|0|T| > +-+-+-+-+ New: +-+-+-+-+ flgs is a set of 4 flags: |0|0|P|T| +-+-+-+-+ and then add something like: The definition and use of the P bit can be found in [RFC 3307]. and make the reference informative. Also, there are no IANA considerations for multicast addresses. But, if you look at the IANA web page (http://www.iana.org/assignments/ipv6-multicast-addresses), it says: > IPv6 multicast addresses are defined in "IP Version 6 Addressing > Architecture" [RFC2373]. This defines fixed scope and variable scope > multicast addresses. But, this document doesn't use the terminology "fixed" or "variable" scope. So things seem out of alignment. Does this document need to straighten things out? Or, maybe it's the case that RFC 3307 is (now) the definitive document? (IANA doesn't seem to have picked up anything from there...). But 3307 document doesn't seem to use the "fixed/variable" terminoligy either. So, it's not immediately clear to me what is needed to get the IANA page cleaned up, but since it _might_ involve tweaking text in this document, I think it would be good to understand what needs to be done before approving this document. It's also not immediately clear to me that this document and rfc 3307 are completely aligned, e.g., in terms of consistent terminology. And this document doesn't seem to reference 3307, which seems incomplete. Nit: > 2.5.3 The Loopback Address > > The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. > It may be used by a node to send an IPv6 packet to itself. It must > not be assigned to any physical interface. It is treated as having > link-local scope, and may be thought of as the link-local unicast > address of a virtual interface (typically called "the loopback > interface") to an imaginary link that goes nowhere. better: ... to an imaginary link to which only a single node attaches, namely the node itself. (issue: the link does go somewhere, since packet sent there loop back...) 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 May 12 13:22:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWHOf-00069a-8h; Thu, 12 May 2005 13:22:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWHOe-00069V-6L for ipv6@megatron.ietf.org; Thu, 12 May 2005 13:22:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13342 for ; Thu, 12 May 2005 13:22:47 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWHeM-0007NV-Ci for ipv6@ietf.org; Thu, 12 May 2005 13:39:07 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4CHMcmD501556 for ; Thu, 12 May 2005 13:22:39 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4CHMcck301406 for ; Thu, 12 May 2005 11:22:38 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4CHMcd9010760 for ; Thu, 12 May 2005 11:22:38 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4CHMcG3010734 for ; Thu, 12 May 2005 11:22:38 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4CHMb6I016417 for ; Thu, 12 May 2005 13:22:37 -0400 Message-Id: <200505121722.j4CHMb6I016417@rotala.raleigh.ibm.com> To: ipv6@ietf.org In-Reply-To: Message from narten@us.ibm.com of "Thu, 12 May 2005 12:50:46 EDT." <200505121650.j4CGoktQ015861@rotala.raleigh.ibm.com> Date: Thu, 12 May 2005 13:22:37 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 > Or, maybe it's the case that RFC 3307 is (now) the definitive > document? (IANA doesn't seem to have picked up anything from > there...). Update (thank you google!): http://www.iana.org/assignments/perm-mcast-groupids Which is findable under "IPv6 Multicast Permanent Group Identifiers" on the main page. But, this (IMO) should be a part of the IPv6 multicast assignments page or at least closely visible there, so one can find it more easily... I.e., from http://www.iana.org/numbers.html: > Internet Protocol version 6 (IPv6) Multicast Address Allocations > Address Allocations RFC3307 Expert Review (Expert-David Meyer) The link to the group identifiers should be here (at a minimum). 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 May 12 15:20:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJEb-00018X-BY; Thu, 12 May 2005 15:20:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJEX-00017W-RS for ipv6@megatron.ietf.org; Thu, 12 May 2005 15:20:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24183 for ; Thu, 12 May 2005 15:20:32 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWJUJ-0001rG-5n for ipv6@ietf.org; Thu, 12 May 2005 15:36:52 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4CJK4k15667; Thu, 12 May 2005 22:20:04 +0300 Date: Thu, 12 May 2005 22:20:04 +0300 (EEST) From: Pekka Savola To: Thomas Narten In-Reply-To: <200505121650.j4CGoktQ015861@rotala.raleigh.ibm.com> Message-ID: References: <200505121650.j4CGoktQ015861@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 Thu, 12 May 2005, Thomas Narten wrote: > This section only mentions the T flag, and not the P flag. That doesnt > seem right, since the P flag is clearly in use now and not "0". Was > there a concern about a possible normative reference? I don't think > there needs to be. Suggestion: > > Old: >> +-+-+-+-+ >> flgs is a set of 4 flags: |0|0|0|T| >> +-+-+-+-+ > > New: > > +-+-+-+-+ > flgs is a set of 4 flags: |0|0|P|T| > +-+-+-+-+ Actually, the bits are currently 0RPT :) -- RFC 3956 (which Updates 3306). -- 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 Thu May 12 16:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJrT-0008PQ-Tb; Thu, 12 May 2005 16:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWJrP-0008OV-EK; Thu, 12 May 2005 16:00:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28547; Thu, 12 May 2005 16:00:41 -0400 (EDT) Message-Id: <200505122000.QAA28547@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 12 May 2005 16:00:41 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2462bis-08.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson, et al. Filename : draft-ietf-ipv6-rfc2462bis-08.txt Pages : 31 Date : 2005-5-12 This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2462bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-12160339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2462bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-12160339.I-D@ietf.org> --OtherAccess-- --NextPart 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 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Thu May 12 17:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLVe-0002YF-6B; Thu, 12 May 2005 17:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWLVb-0002Y7-Dh for ipv6@megatron.ietf.org; Thu, 12 May 2005 17:46:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12249 for ; Thu, 12 May 2005 17:46:16 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWLlO-00077e-6u for ipv6@ietf.org; Thu, 12 May 2005 18:02:39 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id 00E1E218B for ; Thu, 12 May 2005 17:46:15 -0400 (EDT) Received: from [127.0.0.1] (pa772625.cup.hp.com [15.13.128.109]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id DAA20114 for ; Fri, 13 May 2005 03:14:31 +0530 (IST) Message-ID: <4283CEA2.7000402@india.hp.com> Date: Thu, 12 May 2005 14:46:10 -0700 From: Arun Thulasi 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-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: Comments sought: draft-arunt-ipv6-multicast-filtering-rules-00.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arun T 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 Hello All, This is a request to review and comment on the internet draft available at http://www.ietf.org/internet-drafts/draft-arunt-ipv6-multicast-filtering-rules-00.txt The draft is written to explain a set of behaviors in IPv6 multicasting scenarios. Since the behavior seemed to vary on different implementations, this draft specifies both the behaviors and puts forth one of them as preferred. Do look into the draft and offer your comments. Thanks, Arun T -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 13 13:51:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeJk-0006qW-HW; Fri, 13 May 2005 13:51:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeJi-0006oF-NX for ipv6@megatron.ietf.org; Fri, 13 May 2005 13:51:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09375 for ; Fri, 13 May 2005 13:51:17 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWeZg-0001Nx-0G for ipv6@ietf.org; Fri, 13 May 2005 14:07:49 -0400 Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 367155; Fri, 13 May 2005 13:47:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8DA338857B4F404282EE2088005079EA02B1C05E@eammlex037-nb.lmc.ericsson.se> References: <8DA338857B4F404282EE2088005079EA02B1C05E@eammlex037-nb.lmc.ericsson.se> Date: Fri, 13 May 2005 13:50:39 -0400 To: Suresh Krishnan From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ipv6@ietf.org Subject: Re: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-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 At 10:15 AM -0400 5/11/05, Suresh Krishnan wrote: >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 >> 1.2 Conventions used in this document . . . . . . . . . . . . 5 >> >>>> Why is the RFC 2119 section inside the problem statement? > >It is just another sub section under introduction to the document >and is not under the problem statement. I can move this to a >separate section if you feel strongly about this. Oh, okay... I viewed the Problem Statement and the Background both as parts of the problem statement. Maybe if you just switched the order of 1.1 and 1.2 (so the RFC 2119 language comes first), that would be better. Or, just ignore this issue, as it is purely editorial. >> 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 >> 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6 >> 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7 >> 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8 >> 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9 >> >>>> Is section 2 supposed to be part of the problem statement? > >The problem statement is a concise description of the threat model >we are defending against. Section 2 is a much more detailed study of >the problems involved. The problem statement was created to provide >the reader with some context as to why the document is needed. So >the problem statement is a summary of sorts of section 2. Okay. >> 3. Protocol Description >> >> The goal of this section is to define procedures that: >> >> 1. Do not result in any changes to the basic behavior of addresses >> generated via stateless address autoconfiguration [ADDRCONF]. >> 2. Create additional global scope addresses based on a random >> interface identifier for use with global scope addresses. >> >>>> What is meant by "for use with global addresses"? is this intended >> to be a restriction on how/when privacy addresses can be used? > >This is not an intended restriction. I can reword it to read > >"2. Create additional addresses based on a random interface identifier for > the purpose of initiating outgoing sessions" > >instead of > >"2. Create additional global scope addresses based on a random > interface identifier for use with global scope addresses.Such > addresses would be used to initiate outgoing sessions." > >Does that sound OK? Yes, that is better. >> 3.1 Assumptions >> >> The following algorithm assumes that each interface maintains an >> associated randomized interface identifier. When temporary addresses >> are generated, the current value of the associated randomized >> interface identifier is used. The actual value of the identifier >> changes over time as described below, but the same identifier can be >> used to generate more than one temporary address. >> >> The algorithm also assumes that for a given temporary address, an >> implementation can determine the prefix from which it was generated. >> When a temporary address is deprecated, a new temporary address is >> generated. The specific valid and preferred lifetimes for the new >> address are dependent on the corresponding lifetime values set for >> the prefix from which it was generated. >> >>>> These two paragraphs are confusing to me. The node maintains a >> random IID from which multiple addresses can be generated of the >> form , right? These addresses will become deprecated >> when their lifetime expires, and new addresses will be generated. >> The implementation keeps track of what prefix was used to generate >> the addres and generates a new address for that prefix, right? >> Does it also need to generate a new random IID when this happens? >> In other words, is there anything in this mechanism that prevents >> generating the same privacy address again on the same interface >> using the same prefix and the same random IID (if it hasn't expired >> yet)? > >The mechanism certainly allows this behavior but it kind of defeats >the purpose(to not have a stable interface identifier). The >requirement to change the random interface identifier is a SHOULD >and is described in section 3.5 > >" Nodes following this specification SHOULD generate new temporary > addresses on a periodic basis. This can be achieved automatically by > generating a new randomized interface identifier at least once every > (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units." > >If you think this is should be a stronger requirement I can change >it to a MUST at the cost of breaking backward compatibility. Let me >know what you prefer. The SHOULD is fine, but perhaps you could change the first paragraph of section 3.1 to read: The following algorithm assumes that each interface maintains an associated randomized interface identifier. When temporary addresses are generated, the current value of the associated randomized interface identifier is used. While the same identifier can be used to create more than one temporary address, the value SHOULD change over time as described in section 3.5. This would make it clearer that a person should look at section 3.5 to understand how the identifier will change over time. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 13 13:53:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeMI-0007DT-I6; Fri, 13 May 2005 13:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWeMG-0007DO-S6 for ipv6@megatron.ietf.org; Fri, 13 May 2005 13:53:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09611 for ; Fri, 13 May 2005 13:53:55 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWecE-0001Rl-1k for ipv6@ietf.org; Fri, 13 May 2005 14:10: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 j4DHrpLL031561; Fri, 13 May 2005 19:53:51 +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 j4DHruiu024387; Fri, 13 May 2005 19:53:56 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j4DHru4L024386; Fri, 13 May 2005 19:53:56 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 13 May 2005 19:53:56 +0200 From: Stig Venaas To: Arun T Message-ID: <20050513175356.GB24255@storhaugen.uninett.no> References: <4283CEA2.7000402@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4283CEA2.7000402@india.hp.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: Re: Comments sought: draft-arunt-ipv6-multicast-filtering-rules-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 Thu, May 12, 2005 at 02:46:10PM -0700, Arun Thulasi wrote: > Hello All, > > This is a request to review and comment on the internet draft available > at > http://www.ietf.org/internet-drafts/draft-arunt-ipv6-multicast-filtering-rules-00.txt > > The draft is written to explain a set of behaviors in IPv6 multicasting > scenarios. Since the behavior seemed to vary on different > implementations, this draft specifies both the behaviors and puts forth > one of them as preferred. > > Do look into the draft and offer your comments. The behaviour described in 5.2 pretty much matches what I would expect. However, you don't say anything about SSM or the RFC 3678 source filering API. I would like to see the stack doing filtering if necessary, so that when a host joins specific sources (include mode) other packets reaching the host from other sources would not be delivered to the application. And also when in exclude mode, excluding specific sources, the stack should filter in my opinion. In my opinion, the filtering should at least be done so that an application doesn't receive from unwanted sources on the socket where the filter is applied. If the same application or another, creates another socket and binds to the right port and wildcard address or the group address, then I think the best might be to deliver the packets. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 13 13:57:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWePF-00084X-Po; Fri, 13 May 2005 13:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWePD-00084S-Mc for ipv6@megatron.ietf.org; Fri, 13 May 2005 13:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09931 for ; Fri, 13 May 2005 13:56:58 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWefA-0001Zo-Go for ipv6@ietf.org; Fri, 13 May 2005 14:13:30 -0400 Received: from ocean.jinmei.org (PPP293.air-4x8x.dti.ne.jp [210.170.213.67]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 580C515218; Sat, 14 May 2005 02:58:41 +0900 (JST) Date: Sat, 14 May 2005 02:57:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: margaret@thingmagic.com References: <200505122000.QAA28547@ietf.org> 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: multipart/mixed; boundary="Multipart_Sat_May_14_02:57:32_2005-1" X-Spam-Score: 0.2 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: ipv6@ietf.org Subject: Forward: I-D ACTION:draft-ietf-ipv6-rfc2462bis-08.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 --Multipart_Sat_May_14_02:57:32_2005-1 Content-Type: text/plain; charset=US-ASCII Hi Margaret, A new version of the rfc2462bis draft is now available, in which I believe I've resolved all IESG comments except this one from Allison: No updated implementation report; I'd like to see reporting in there of the basis for the dropping of the Managed bit, which is stated in the draft as an implementation result. It's a good simplification, it sounds like, but documenting this in the report would be good. Didn't the reading of 2026 come out updated implementation reports for recycling DS's? I've asked related questions about this comment on the wg list two times, including requested information at the Minneapolis meeting, but I've not got any responses...if this comment does not require any change to the document itself, I believe we are done. If it does, or if it requires any particular action (e.g., collecting implementation report), please clarify that. Please also note that the following comment, also from Allison, may be a blocking issue in a procedural sense: There is a lot of normative dependency on the recycling DS of Neighbory Discovery which not even in the tracker yet, so are there some instabilities? As I answered at this list, 2461bis and 2462bis should be updated at the same timing, so we'll eventually need to wait for 2461bis to be approved. If we reach the point, please just keep 2461bis sleeping for now. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Sat_May_14_02:57:32_2005-1 Content-Type: message/rfc822 X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@isl.rdc.toshiba.co.jp Message-Id: <200505122000.QAA28547@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 12 May 2005 16:00:41 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2462bis-08.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 Status: U X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on ocean.jinmei.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson, et al. Filename : draft-ietf-ipv6-rfc2462bis-08.txt Pages : 31 Date : 2005-5-12 This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2462bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-12160339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2462bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-12160339.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --NextPart-- --Multipart_Sat_May_14_02:57:32_2005-1 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 -------------------------------------------------------------------- --Multipart_Sat_May_14_02:57:32_2005-1-- From ipv6-bounces@ietf.org Fri May 13 14:28:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWetE-0004PW-29; Fri, 13 May 2005 14:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWetC-0004PR-QX for ipv6@megatron.ietf.org; Fri, 13 May 2005 14:27:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11891 for ; Fri, 13 May 2005 14:27:57 -0400 (EDT) Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DWf9A-0002j0-FH for ipv6@ietf.org; Fri, 13 May 2005 14:44:29 -0400 Received: (qmail 29624 invoked for bounce); 13 May 2005 18:27:40 -0000 Received: from unknown (HELO ?192.168.0.3?) (hoerdt@unknown) by unknown with RC4-MD5 encrypted SMTP; 13 May 2005 18:27:40 -0000 Message-ID: <4284F189.2030601@clarinet.u-strasbg.fr> Date: Fri, 13 May 2005 20:27:21 +0200 From: Hoerdt Mickael User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Arun T References: <4283CEA2.7000402@india.hp.com> In-Reply-To: <4283CEA2.7000402@india.hp.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA11891 Cc: ipv6@ietf.org Subject: Re: Comments sought: draft-arunt-ipv6-multicast-filtering-rules-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 Arun, Thanks for this work, I think it can be very useful for multicast application writers. Here are my comments : Section 3: You say that the current behavior is implementation specific, could you give some references/samples ? My experience is that the multicast socket/setsockopt behavior is quite standard among implementations even is sometime functions arguments are changing... Section 4: I guess that you want to say "Multicast socket" instead of multicast client in this section. Reducing multicast applications to Client and Server with a destination and source port is quite dangerous here I think. That's of course the way how current simple multicast applications are working today but keeping the idea more general, multicast applications may contains several sockets corresponding to several protocols and joining several groups. Also, you use the words host/node/client independantly, I understand them as "sockets". Section 5: I dont think that I agree with this section, why should every applications should listens to some special multicast adresses ? I think my disagreement is a consequence of the socket/Application/client definition. Section 6: The behaviour is what I would expect from a system. Please note that the information present in this section is redundant with RFC3678. Cheers, Hoerdt Micka=EBl Arun Thulasi wrote: > Hello All, > > This is a request to review and comment on the internet draft > available at > http://www.ietf.org/internet-drafts/draft-arunt-ipv6-multicast-filterin= g-rules-00.txt > > > The draft is written to explain a set of behaviors in IPv6 > multicasting scenarios. Since the behavior seemed to vary on different > implementations, this draft specifies both the behaviors and puts > forth one of them as preferred. > > Do look into the draft and offer your comments. > > Thanks, > Arun T > > > -------------------------------------------------------------------- > 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 Sat May 14 04:34:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWs6m-0005bK-Kh; Sat, 14 May 2005 04:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWs6k-0005b3-31; Sat, 14 May 2005 04:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14145; Sat, 14 May 2005 04:34:47 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWsMp-0004tJ-SS; Sat, 14 May 2005 04:51:28 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 209B715210; Sat, 14 May 2005 17:36:43 +0900 (JST) Date: Sat, 14 May 2005 17:35:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola In-Reply-To: References: <1114538312.6886.17.camel@localhost.localdomain> 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: 31247fb3be228bb596db9127becad0bc Cc: dhcwg@ietf.org, IPv6 WG , Ralph Droms Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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, 26 Apr 2005 21:17:33 +0300 (EEST), >>>>> Pekka Savola said: >>>> I can think of several possible resolutions: >>>> >>>> 1. just say that it's host/network administrator's responsibility to >>>> provide consistent parameters/configurations. In this sense, the >>>> combination of a) and b) above is just a configuration error. >>>> This would be the most lightweight resolution for the authors:-), >>>> but I personally think it's irresponsible. >>> >>> I agree as well. This is not good enough. >> >> I think it's perfectly reasonable to assume that a configuration >> mismatch is admin error and leave it at that - in this case, the RAs are >> configured incorrectly, promising that a non-existent address assignment >> service is available. > That would be consistent if the presence of M-flag would only trigger > DHCPv6 for address assignment, but DHCPv6 would not be used to > configure anything else at all unless O-flag was also appropriately > set. > Then the DHCPv6 and DHCPv6-lite would function in a similar fashion > from the network administrator's perspective. > So, IMHO, either we must require O flag always for Information > Configuration (whether DHCPv6 full or lite) or support the > administrators who can't make out the subtle difference about the > appropriate configuration of the flags. For that, guidance for full > DHCPv6 implementers to also try emulating DHCPv6 lite would probably > be sufficient. I've been thinking about this issue for a while, and I now feel it may require a more profound discussion than I originally thought... Here are some background points: - In original RFC2462, if ManagedFlag (host's variable corresponding to the M flag of RA) is TRUE, it implicitly means OtherConfigFlag is also TRUE (Section 5.2). It would mean if we receive an RA with M=on (whether O=on or off), the receiving host would start the "stateful" protocol (which we now know is DHCPv6) for address configuration *and* the "stateful" protocol for configuration information excluding addresses (Section 5.5.3). - In the past discussion about the M/O flag document, we clarified that the notion of "M" and "O" is quite independent. That is, "M" means the "Host Configuration Behavior", which, more specifically, means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O" means the "Information Configuration Behavior", which means DHCPv6 an Information-request/Reply exchange. Unlike RFC2462, there is no implicit dependency between "O-Flag" (renamed from OtherConfigFlag to avoid confusion) and the M flag in this document. So, for example, the host does not invoke the "Information Configuration Behavior" just because the M flag in an RA is ON. I guess the slightly different sense led us to the current confusion (or problem). If we respect both the original sense of RFC2462 and our consensus about the semantics separation of the M/O flags, I believe the right solution is the following: - allow (or even require) running the Host Configuration Behavior and the Information Configuration Behavior concurrently. (note: this is a significant change from the current M/O document) - note that the same type of configuration information (e.g., recursive DNS server addresses) can be obtained with those two behaviors, and that how to deal with possible inconsistency is beyond the scope of the M/O document. - also note that the network administrator should by default provide the Information Configuration Behavior when they provide the Host Configuration Behavior, in which case both the M and O flags should be set to ON in router advertisements. With the last notice, I'm fine with the position of saying "it's administrator's responsibility to ensure service consistency". 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 Sat May 14 12:28:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWzV9-0007CC-1K; Sat, 14 May 2005 12:28:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWzV6-0007C4-9z for ipv6@megatron.ietf.org; Sat, 14 May 2005 12:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15440 for ; Sat, 14 May 2005 12:28:24 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWzlF-0005cW-9s for ipv6@ietf.org; Sat, 14 May 2005 12:45:10 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 9F94C133; Sat, 14 May 2005 12:26:28 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 14 May 2005 12:28:13 -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: Sat, 14 May 2005 12:27:34 -0400 Message-ID: <936A4045C332714F975800409DE092403F05C8@tayexc14.americas.cpqcorp.net> Thread-Topic: Flow Label consistency question Thread-Index: AcVJoscWdLhDhXlRSRiFpPYzh+COVwO/wAbQ From: "Bound, Jim" To: "Brian E Carpenter" , "Ran Liebermann" X-OriginalArrivalTime: 14 May 2005 16:28:13.0183 (UTC) FILETIME=[EC90F8F0:01C558A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Flow Label consistency question 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 Please read the drafts it is restored. WOW. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Brian E Carpenter > Sent: Monday, April 25, 2005 9:21 AM > To: Ran Liebermann > Cc: ipv6@ietf.org > Subject: Re: Flow Label consistency question >=20 > Ran Liebermann wrote: > ... > > I still see much more benefit in using the Flow Label for 6SLAs. > > If this indeed will be a common use for the Flow Label then=20 > we should > > take into consideration that probably many (if not most) service > > providers will not allow their customers to set the Flow Label field > > and enforce a zero label on all ingress traffic in order to allow > > 6SLAs to work properly. >=20 > Until 6LSA explains how it will restore the label to its > original value, or the IETF changes its mind about immutability > of the label, this just isn't going to happen. I think that's > why the 6LSA people wrote their recent draft. >=20 > > Ofcourse if the label will also be used to classify traffic for > > diffserv then this is one more reason for SPs to override=20 > the label to > > zero on all ingress traffic from customers. >=20 > Quite the opposite. In a diffserv model, the value of the label > set by the source will be *input* to a diffserv domain boundary's > diffserv classifier, just like the protocol number or port numbers. > That's one of the use cases in which immutability of the label > is a vital property. >=20 > Brian >=20 > > Ran. > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=20 >=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 Sat May 14 12:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWzWz-0007PB-RJ; Sat, 14 May 2005 12:30:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWzWw-0007Ok-Rw for ipv6@megatron.ietf.org; Sat, 14 May 2005 12:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15527 for ; Sat, 14 May 2005 12:30:19 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWzn7-0005i4-9y for ipv6@ietf.org; Sat, 14 May 2005 12:47:05 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 5C557133; Sat, 14 May 2005 12:28:29 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 14 May 2005 12:30:13 -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: Sat, 14 May 2005 12:29:29 -0400 Message-ID: <936A4045C332714F975800409DE092403F05C9@tayexc14.americas.cpqcorp.net> Thread-Topic: Flow Label consistency question Thread-Index: AcVJrQ8tKySGNOOTRqaT8kRD2xBBkQO9OWvg From: "Bound, Jim" To: "Kit Plummer" , "Ran Liebermann" X-OriginalArrivalTime: 14 May 2005 16:30:13.0897 (UTC) FILETIME=[34847790:01C558A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: Brian E Carpenter , ipv6@ietf.org Subject: RE: Flow Label consistency question 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 flow label must be kept e2e is my interpretation. Also I don't believe routers or SPs should be resetting Traffic Class and that may be a bug if this is not the case. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Kit Plummer > Sent: Monday, April 25, 2005 11:37 AM > To: Ran Liebermann > Cc: Brian E Carpenter; ipv6@ietf.org > Subject: Re: Flow Label consistency question >=20 >=20 > On Apr 25, 2005, at 8:23 AM, Ran Liebermann wrote: >=20 > > Hi Brian and all, > > > > On 25/04/05, Brian E Carpenter wrote: > > > >> Until 6LSA explains how it will restore the label to its > >> original value, or the IETF changes its mind about immutability > >> of the label, this just isn't going to happen. I think that's > >> why the 6LSA people wrote their recent draft. > >> > > > > On this you're right. Unless a new standard will obsolete=20 > RFC 3697 the > > label has to be restored to the original value. > > But this is exactly the point - there is no apparent necessity to > > restore the original value. If it should be used for QoS the value > > should only mean something to nodes on the path of the flow, because > > after it reaches it's destination then QoS is not important anymore > > (but anyhow we have the Traffic Class byte for that). If it=20 > should be > > used for LSAs/TE the value shouldn't matter to the final destination > > again but only to nodes in the flow's path. If it should be used for > > some sort of a signalling to the destination - why shouldn't this > > signalling be embedded in upper layers data? > > > > The only reason for the value of be kept e2e is if this value should > > signal something to routers in the path of the flow (the reason why > > not including the value in upper layers) and still be used by the > > destination for something (for example - so that the=20 > destination would > > know what value the source put in there in order to insert=20 > a new value > > for returning traffic which has a meaning that's derived from the > > former value of the original data). Can you think of an application > > for that? >=20 > Lower-level Flow(data) classification. Think isolated (or not), =20 > military networks. >=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 Sat May 14 13:01:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX01U-00052J-U4; Sat, 14 May 2005 13:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX01T-00052E-Je for ipv6@megatron.ietf.org; Sat, 14 May 2005 13:01:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17929 for ; Sat, 14 May 2005 13:01:52 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX0Hd-0006vJ-9l for ipv6@ietf.org; Sat, 14 May 2005 13:18:38 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8AF6EF5 for ; Sat, 14 May 2005 13:00:00 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 14 May 2005 13:01:44 -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: Sat, 14 May 2005 13:01:16 -0400 Message-ID: <936A4045C332714F975800409DE092403F05D4@tayexc14.americas.cpqcorp.net> Thread-Topic: 6LSA Slides and QoS Thread-Index: AcVYpoqH9JqRtGfkQpSIJqg3YS09Gw== From: "Bound, Jim" To: X-OriginalArrivalTime: 14 May 2005 17:01:45.0168 (UTC) FILETIME=[9BCD8500:01C558A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: 6LSA Slides and QoS 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 You can see good example of 6LSA in Charts at: http://www.nav6tf.org/documents/arin-nav6tf-apr05/5.QoS_and_IPv6_SC.pdf The rest of the slides for IPv6 may be interesting to some from this joint ARIN+NAv6TF meeting too. http://www.nav6tf.org/html/nav6tf_events.html /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun May 15 00:00:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXAIw-0000sV-Nr; Sun, 15 May 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 1DXAIu-0000sO-9v for ipv6@megatron.ietf.org; Sun, 15 May 2005 00:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04111 for ; Sun, 15 May 2005 00:00:33 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXAZ9-0001tH-PS for ipv6@ietf.org; Sun, 15 May 2005 00:17:25 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 260FB2B5 for ; Sun, 15 May 2005 00:00:18 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 15 May 2005 00:00:18 -0400 Message-Id: <20050515040018.260FB2B5@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 --------+------+--------+----------+------------------------ 10.71% | 3 | 20.57% | 40648 | arunt@india.hp.com 21.43% | 6 | 9.77% | 19306 | rt+ipv6-2462bis@rt.psg.com 14.29% | 4 | 12.59% | 24866 | jinmei@isl.rdc.toshiba.co.jp 3.57% | 1 | 16.31% | 32225 | sachind@huawei.com 10.71% | 3 | 7.17% | 14161 | jim.bound@hp.com 7.14% | 2 | 7.27% | 14372 | margaret@thingmagic.com 7.14% | 2 | 5.32% | 10508 | narten@us.ibm.com 3.57% | 1 | 5.36% | 10595 | brian@innovationslab.net 3.57% | 1 | 3.99% | 7887 | suresh.krishnan@ericsson.ca 3.57% | 1 | 2.93% | 5786 | internet-drafts@ietf.org 3.57% | 1 | 2.57% | 5078 | hoerdt@clarinet.u-strasbg.fr 3.57% | 1 | 2.29% | 4527 | stig.venaas@uninett.no 3.57% | 1 | 2.03% | 4015 | sra+ipng@hactrn.net 3.57% | 1 | 1.82% | 3604 | pekkas@netcore.fi --------+------+--------+----------+------------------------ 100.00% | 28 |100.00% | 197578 | 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 Sun May 15 11:18:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXKse-0001Hn-S4; Sun, 15 May 2005 11:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXKsd-0001Hi-Rh for ipv6@megatron.ietf.org; Sun, 15 May 2005 11:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29065 for ; Sun, 15 May 2005 11:18:09 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXL8z-0005In-DE for ipv6@ietf.org; Sun, 15 May 2005 11:35:06 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.3]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 367871; Sun, 15 May 2005 11:13:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200505122000.QAA28547@ietf.org> Date: Sun, 15 May 2005 11:17:49 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipv6@ietf.org Subject: Re: Forward: I-D ACTION:draft-ietf-ipv6-rfc2462bis-08.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 Jinmei, At 2:57 AM +0900 5/14/05, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >I've asked related questions about this comment on the wg list two >times, including requested information at the Minneapolis meeting, but >I've not got any responses...if this comment does not require any >change to the document itself, I believe we are done. If it does, or >if it requires any particular action (e.g., collecting implementation >report), please clarify that. It sounds like he document is ready, which is great, thanks! It is up to the WG Chairs, Bob and Brian, to put together an implementation report. In this particular case, this may only involve pointing at the old implementation report and explaining why the changes in this document do not warrant gathering further implementation data. I will work with Bob and Brian on this. >As I answered at this list, 2461bis and 2462bis should be updated at >the same timing, so we'll eventually need to wait for 2461bis to be >approved. If we reach the point, please just keep 2461bis sleeping >for now. Brian and Bob, what is the status on 2461bis? Are we expecting it to be submitted for publication soon? Thanks, Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun May 15 11:32:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXL6M-00048Y-RA; Sun, 15 May 2005 11:32:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXL6K-00048Q-N7 for ipv6@megatron.ietf.org; Sun, 15 May 2005 11:32:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00570 for ; Sun, 15 May 2005 11:32:17 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXLMg-0005eP-8r for ipv6@ietf.org; Sun, 15 May 2005 11:49:15 -0400 Received: from ocean.jinmei.org (PPP443.air-4x8x.dti.ne.jp [210.170.213.232]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CB11715210; Mon, 16 May 2005 00:34:11 +0900 (JST) Date: Mon, 16 May 2005 00:33:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: margaret@thingmagic.com, ipv6@ietf.org In-Reply-To: References: <200505122000.QAA28547@ietf.org> 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.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: Re: Forward: I-D ACTION:draft-ietf-ipv6-rfc2462bis-08.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 Sat, 14 May 2005 02:57:33 +0900, >>>>> JINMEI Tatuya said: > As I answered at this list, 2461bis and 2462bis should be updated at > the same timing, so we'll eventually need to wait for 2461bis to be > approved. If we reach the point, please just keep 2461bis sleeping > for now. Oops...although this should be pretty clear from the context, I meant in the last sentence that "...please just keep *2462bis* sleeping for now". Sorry for the possible confusion. 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 Mon May 16 09:56:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXg5U-0005hm-B2; Mon, 16 May 2005 09:56:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXg5P-0005ec-Sr; Mon, 16 May 2005 09:56:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14046; Mon, 16 May 2005 09:56:46 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXgLw-0004bj-Pz; Mon, 16 May 2005 10:13:54 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 May 2005 10:12:19 -0400 X-IronPort-AV: i="3.93,111,1115006400"; d="scan'208"; a="49575145:sNHT32825652" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GDu7nW025063; Mon, 16 May 2005 09:56:34 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 09:56:27 -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: Mon, 16 May 2005 09:56:26 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVYYFPIrJ1r0kF3RvCSQN0HVF4HVwBvUAwA From: "Bernie Volz \(volz\)" To: "JINMEI Tatuya / ????" , "Pekka Savola" X-OriginalArrivalTime: 16 May 2005 13:56:27.0610 (UTC) FILETIME=[0E0C4BA0:01C55A1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IPv6 WG , "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 haven't followed this thread carefully, but are you trying to suggest that if the M flag is set but O is not, that a client would IGNORE the other configuration parameters received from a DHCP server in a Solicit/Advertise/Request/Reply sequence? That seems very bad to me. And a waste of resources to have to do two sets of transactions (Solicit/Advertise/Request/Reply for addresses and Information-Request/Reply for other configuration). I really don't understand why this issue has been so difficult to resolve. In IPv4, DHCP is often the default unless you explicitly configure an interface or turn DHCP off. We don't have ANY network wide configuration for this. And it works very well indeed. In IPv6, the M and O flag should serve as hints. Period. A host is perfectly free to do what it wants (or what it has been configured to do). The M flag, if set, means a host SHOULD do full-RFC 3315. This means they should attempt to Solicit, but can also fall back to Information-Request if needed. This means both addresses and other configuration are configured, if available. The O flag, if set, means a host SHOULD do RFC 3376 (partial RFC 3315). If both flags are set, hosts that can do full RFC 3315 do it (and ignore the O flag). Those that can only do RFC 3376, do that. If no flag it set, hosts may still do RFC 3315 and/or 3376 if so configured (whether by default or otherwise). There should be no prohibition against doing that. The document need not say this - it is implied because we MUST NOT use MUST or MUST NOT. Just SHOULD or SHOULD NOT when taking about the bits. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of jinmei@isl.rdc.toshiba.co.jp > Sent: Saturday, May 14, 2005 4:36 AM > To: Pekka Savola > Cc: dhcwg@ietf.org; IPv6 WG; Ralph Droms (rdroms) > Subject: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > >>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST),=20 > >>>>> Pekka Savola said: >=20 > >>>> I can think of several possible resolutions: > >>>>=20 > >>>> 1. just say that it's host/network administrator's=20 > responsibility to > >>>> provide consistent parameters/configurations. In this sense, the > >>>> combination of a) and b) above is just a configuration error. > >>>> This would be the most lightweight resolution for the authors:-), > >>>> but I personally think it's irresponsible. > >>>=20 > >>> I agree as well. This is not good enough. > >>=20 > >> I think it's perfectly reasonable to assume that a configuration > >> mismatch is admin error and leave it at that - in this=20 > case, the RAs are > >> configured incorrectly, promising that a non-existent=20 > address assignment > >> service is available. >=20 > > That would be consistent if the presence of M-flag would=20 > only trigger=20 > > DHCPv6 for address assignment, but DHCPv6 would not be used to=20 > > configure anything else at all unless O-flag was also appropriately=20 > > set. >=20 > > Then the DHCPv6 and DHCPv6-lite would function in a similar fashion=20 > > from the network administrator's perspective. >=20 > > So, IMHO, either we must require O flag always for Information=20 > > Configuration (whether DHCPv6 full or lite) or support the=20 > > administrators who can't make out the subtle difference about the=20 > > appropriate configuration of the flags. For that, guidance=20 > for full=20 > > DHCPv6 implementers to also try emulating DHCPv6 lite would=20 > probably=20 > > be sufficient. >=20 > I've been thinking about this issue for a while, and I now feel it may > require a more profound discussion than I originally thought... >=20 > Here are some background points: >=20 > - In original RFC2462, if ManagedFlag (host's variable corresponding > to the M flag of RA) is TRUE, it implicitly means OtherConfigFlag is > also TRUE (Section 5.2). It would mean if we receive an RA with > M=3Don (whether O=3Don or off), the receiving host would start the > "stateful" protocol (which we now know is DHCPv6) for address > configuration *and* the "stateful" protocol for configuration > information excluding addresses (Section 5.5.3). >=20 > - In the past discussion about the M/O flag document, we clarified > that the notion of "M" and "O" is quite independent. That is, "M" > means the "Host Configuration Behavior", which, more specifically, > means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O" > means the "Information Configuration Behavior", which means DHCPv6 > an Information-request/Reply exchange. Unlike RFC2462, there is no > implicit dependency between "O-Flag" (renamed from OtherConfigFlag > to avoid confusion) and the M flag in this document. So, for > example, the host does not invoke the "Information Configuration > Behavior" just because the M flag in an RA is ON. >=20 > I guess the slightly different sense led us to the current confusion > (or problem). >=20 > If we respect both the original sense of RFC2462 and our consensus > about the semantics separation of the M/O flags, I believe the right > solution is the following: >=20 > - allow (or even require) running the Host Configuration Behavior > and the Information Configuration Behavior concurrently. (note: > this is a significant change from the current M/O document) > - note that the same type of configuration information (e.g., > recursive DNS server addresses) can be obtained with those two > behaviors, and that how to deal with possible inconsistency is > beyond the scope of the M/O document. > - also note that the network administrator should by default provide > the Information Configuration Behavior when they provide the Host > Configuration Behavior, in which case both the M and O flags > should be set to ON in router advertisements. >=20 > With the last notice, I'm fine with the position of saying "it's > administrator's responsibility to ensure service consistency". >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 13:11:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXj8H-0007b3-Qr; Mon, 16 May 2005 13:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXj8F-0007av-G9; Mon, 16 May 2005 13:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12211; Mon, 16 May 2005 13:11:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjOp-000426-CS; Mon, 16 May 2005 13:29:03 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 May 2005 13:11:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4GHB3ea018839; Mon, 16 May 2005 13:11:43 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 13:11:42 -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: Mon, 16 May 2005 13:11:41 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVYYFPIrJ1r0kF3RvCSQN0HVF4HVwBvUAwAAAahuqA= From: "Bernie Volz \(volz\)" To: "JINMEI Tatuya / ????" , "Pekka Savola" X-OriginalArrivalTime: 16 May 2005 17:11:42.0100 (UTC) FILETIME=[546D9D40:01C55A3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IPv6 WG , "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 BTW, if you want to look at this from the router administrator's perspective: Configure the router to send the M flag set in routing advertisements for a Link IF: 1. A stateful DHCP server is deployed for that link (either on it or reachable via a relay agent) AND 2. At least ONE or more prefixes the router is advertising for that link are NOT configured for stateless auto-configuration. Configure the router to send the O flag set in routing advertisements for a link IF: 1. A stateful or stateless DHCP server is deployed for that link (either on it or reachable via a relay agent) AND 2. At least ONE or more prefixes the router is advertising for that link ALLOW stateless auto-configuration OR there are resources available to the clients on that link that are reachable via link-local addresses (such as an SNTP server). The latter may change over time depending on what other configuration settings are available, but with the present set of IETF options there is little value in providing any of the other configuration settings if the client can only use link-local addresses. So, the 4 possible combinations of the M&O bit may appear and be used. For example, the M may be set but the O clear if no stateless auto configuration for any address is possible (and there are no link-local resources available to the client that can be configured via DHCP). The M may be clear if there are no stateful addresses for the link. In this case, the O would be set if there are more than link-local addresses advertised. Both the M & O would be set if one or more stateful addresses is present, but stateless addresses are also available. Clients that don't support stateful would still need the other configuration parameters and could likely communicate with those resources since they have non-link-local addresses. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Bernie Volz (volz) > Sent: Monday, May 16, 2005 9:56 AM > To: JINMEI Tatuya / ????; Pekka Savola > Cc: dhcwg@ietf.org; IPv6 WG; Ralph Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > I haven't followed this thread carefully, but are you trying > to suggest > that if the M flag is set but O is not, that a client would IGNORE the > other configuration parameters received from a DHCP server in a > Solicit/Advertise/Request/Reply sequence? That seems very bad > to me. And > a waste of resources to have to do two sets of transactions > (Solicit/Advertise/Request/Reply for addresses and > Information-Request/Reply for other configuration). > > I really don't understand why this issue has been so difficult to > resolve. > > In IPv4, DHCP is often the default unless you explicitly configure an > interface or turn DHCP off. We don't have ANY network wide > configuration > for this. And it works very well indeed. > > In IPv6, the M and O flag should serve as hints. Period. A host is > perfectly free to do what it wants (or what it has been configured to > do). > > The M flag, if set, means a host SHOULD do full-RFC 3315. This means > they should attempt to Solicit, but can also fall back to > Information-Request if needed. This means both addresses and other > configuration are configured, if available. > > The O flag, if set, means a host SHOULD do RFC 3376 (partial > RFC 3315). > > If both flags are set, hosts that can do full RFC 3315 do it > (and ignore > the O flag). Those that can only do RFC 3376, do that. > > If no flag it set, hosts may still do RFC 3315 and/or 3376 if so > configured (whether by default or otherwise). There should be no > prohibition against doing that. The document need not say this - it is > implied because we MUST NOT use MUST or MUST NOT. Just SHOULD > or SHOULD > NOT when taking about the bits. > > - Bernie > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of jinmei@isl.rdc.toshiba.co.jp > > Sent: Saturday, May 14, 2005 4:36 AM > > To: Pekka Savola > > Cc: dhcwg@ietf.org; IPv6 WG; Ralph Droms (rdroms) > > Subject: [dhcwg] Re: IPv6 WG Last > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > > > >>>>> On Tue, 26 Apr 2005 21:17:33 +0300 (EEST), > > >>>>> Pekka Savola said: > > > > >>>> I can think of several possible resolutions: > > >>>> > > >>>> 1. just say that it's host/network administrator's > > responsibility to > > >>>> provide consistent parameters/configurations. In this > sense, the > > >>>> combination of a) and b) above is just a configuration error. > > >>>> This would be the most lightweight resolution for the > authors:-), > > >>>> but I personally think it's irresponsible. > > >>> > > >>> I agree as well. This is not good enough. > > >> > > >> I think it's perfectly reasonable to assume that a configuration > > >> mismatch is admin error and leave it at that - in this > > case, the RAs are > > >> configured incorrectly, promising that a non-existent > > address assignment > > >> service is available. > > > > > That would be consistent if the presence of M-flag would > > only trigger > > > DHCPv6 for address assignment, but DHCPv6 would not be used to > > > configure anything else at all unless O-flag was also > appropriately > > > set. > > > > > Then the DHCPv6 and DHCPv6-lite would function in a > similar fashion > > > from the network administrator's perspective. > > > > > So, IMHO, either we must require O flag always for Information > > > Configuration (whether DHCPv6 full or lite) or support the > > > administrators who can't make out the subtle difference about the > > > appropriate configuration of the flags. For that, guidance > > for full > > > DHCPv6 implementers to also try emulating DHCPv6 lite would > > probably > > > be sufficient. > > > > I've been thinking about this issue for a while, and I now > feel it may > > require a more profound discussion than I originally thought... > > > > Here are some background points: > > > > - In original RFC2462, if ManagedFlag (host's variable corresponding > > to the M flag of RA) is TRUE, it implicitly means > OtherConfigFlag is > > also TRUE (Section 5.2). It would mean if we receive an RA with > > M=3Don (whether O=3Don or off), the receiving host would start the > > "stateful" protocol (which we now know is DHCPv6) for address > > configuration *and* the "stateful" protocol for configuration > > information excluding addresses (Section 5.5.3). > > > > - In the past discussion about the M/O flag document, we clarified > > that the notion of "M" and "O" is quite independent. That is, "M" > > means the "Host Configuration Behavior", which, more specifically, > > means DHCPv6 Solicit/Advertise/Request/Reply/... exchanges; "O" > > means the "Information Configuration Behavior", which means DHCPv6 > > an Information-request/Reply exchange. Unlike RFC2462, > there is no > > implicit dependency between "O-Flag" (renamed from OtherConfigFlag > > to avoid confusion) and the M flag in this document. So, for > > example, the host does not invoke the "Information Configuration > > Behavior" just because the M flag in an RA is ON. > > > > I guess the slightly different sense led us to the current confusion > > (or problem). > > > > If we respect both the original sense of RFC2462 and our consensus > > about the semantics separation of the M/O flags, I believe the right > > solution is the following: > > > > - allow (or even require) running the Host Configuration Behavior > > and the Information Configuration Behavior concurrently. (note: > > this is a significant change from the current M/O document) > > - note that the same type of configuration information (e.g., > > recursive DNS server addresses) can be obtained with those two > > behaviors, and that how to deal with possible inconsistency is > > beyond the scope of the M/O document. > > - also note that the network administrator should by > default provide > > the Information Configuration Behavior when they > provide the Host > > Configuration Behavior, in which case both the M and O flags > > should be set to ON in router advertisements. > > > > With the last notice, I'm fine with the position of saying "it's > > administrator's responsibility to ensure service consistency". > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 13:21:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjHT-0001GU-KO; Mon, 16 May 2005 13:21:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjHR-0001GL-De; Mon, 16 May 2005 13:21:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13336; Mon, 16 May 2005 13:21:20 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjXw-0004VT-DW; Mon, 16 May 2005 13:38:31 -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 j4GHLALL013727; Mon, 16 May 2005 19:21:10 +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 j4GHLKLe022681; Mon, 16 May 2005 19:21:20 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j4GHLKx7022680; Mon, 16 May 2005 19:21:20 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 16 May 2005 19:21:20 +0200 From: Stig Venaas To: "Bernie Volz (volz)" Message-ID: <20050516172120.GA22530@storhaugen.uninett.no> References: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , Pekka Savola , JINMEI Tatuya / ???? Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Another reason they need to be only hints to the clients, is that there might be many different types of clients on the same link. I think there are many cases where you don't want to force all the clients to do the same. One thing is what information a client wants to obtain, another is what it supports. Does the client do DHCP at all, does it just do state- less, or does it do the full 3315. 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 May 16 13:50:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjj8-0008CJ-H8; Mon, 16 May 2005 13:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXjj6-0008Bv-W1; Mon, 16 May 2005 13:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16358; Mon, 16 May 2005 13:49:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXjze-0005ik-Hu; Mon, 16 May 2005 14:07:09 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 May 2005 13:49:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GHnCnk007859; Mon, 16 May 2005 13:49:46 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 13:49:43 -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: Mon, 16 May 2005 13:49:42 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B349C@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVaO7qacjUC63UyRmyhTG/+d1ICtAAA8+pQ From: "Bernie Volz \(volz\)" To: "Stig Venaas" X-OriginalArrivalTime: 16 May 2005 17:49:43.0274 (UTC) FILETIME=[A41D24A0:01C55A3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , Pekka Savola , JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Exactly!=20 > -----Original Message----- > From: Stig Venaas [mailto:Stig.Venaas@uninett.no]=20 > Sent: Monday, May 16, 2005 1:21 PM > To: Bernie Volz (volz) > Cc: JINMEI Tatuya / ????; Pekka Savola; dhcwg@ietf.org; IPv6=20 > WG; Ralph Droms (rdroms) > Subject: Re: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Another reason they need to be only hints to the clients, is=20 > that there > might be many different types of clients on the same link. I=20 > think there > are many cases where you don't want to force all the clients to do the > same. One thing is what information a client wants to obtain,=20 > another is > what it supports. Does the client do DHCP at all, does it=20 > just do state- > less, or does it do the full 3315. >=20 > Stig >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 14:28:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkKd-00086e-VV; Mon, 16 May 2005 14:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkKZ-0007we-Tg for ipv6@megatron.ietf.org; Mon, 16 May 2005 14:28:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20366 for ; Mon, 16 May 2005 14:28:42 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXkbA-0007LQ-MH for ipv6@ietf.org; Mon, 16 May 2005 14:45:53 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11745498; Mon, 16 May 2005 14:27:58 -0400 In-Reply-To: <200505121650.j4CGoktQ015861@rotala.raleigh.ibm.com> References: <200505121650.j4CGoktQ015861@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <3d574c20ee7d9fd5ffac393ab4dad1de@innovationslab.net> From: Brian Haberman Date: Mon, 16 May 2005 14:27:56 -0400 To: Thomas Narten X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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="===============0029605042==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0029605042== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-521923569; protocol="application/pkcs7-signature" --Apple-Mail-3-521923569 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Thomas, On May 12, 2005, at 12:50, Thomas Narten wrote: > I know this is late, but better late than never... > > Overall, the document is good, but I think that the document would > benefit from slight tweaking w.r.t. to multicast. I.e., I assume that > an "addressing architecture" should be complete and at a minimum offer > pointers to the relevant pieces. I don't think it quite does that in > the case of multicast. > >> 2.7 Multicast Addresses > > This section only mentions the T flag, and not the P flag. That doesnt > seem right, since the P flag is clearly in use now and not "0". Was > there a concern about a possible normative reference? I don't think > there needs to be. Suggestion: > > Old: >> +-+-+-+-+ >> flgs is a set of 4 flags: |0|0|0|T| >> +-+-+-+-+ > > New: > > +-+-+-+-+ > flgs is a set of 4 flags: |0|0|P|T| > +-+-+-+-+ > > and then add something like: > > The definition and use of the P bit can be found in [RFC 3307]. > > and make the reference informative. Bob and I discussed this and he will be putting text together that clarifies the bits with informative references to RFC 3306 (not 3307) and RFC 3956. > > Also, there are no IANA considerations for multicast addresses. But, > if you look at the IANA web page > (http://www.iana.org/assignments/ipv6-multicast-addresses), it says: > >> IPv6 multicast addresses are defined in "IP Version 6 Addressing >> Architecture" [RFC2373]. This defines fixed scope and variable scope >> multicast addresses. > > But, this document doesn't use the terminology "fixed" or "variable" > scope. So things seem out of alignment. Does this document need to > straighten things out? > > Or, maybe it's the case that RFC 3307 is (now) the definitive > document? (IANA doesn't seem to have picked up anything from > there...). But 3307 document doesn't seem to use the "fixed/variable" > terminoligy either. > > So, it's not immediately clear to me what is needed to get the IANA > page cleaned up, but since it _might_ involve tweaking text in this > document, I think it would be good to understand what needs to be > done before approving this document. > > It's also not immediately clear to me that this document and rfc 3307 > are completely aligned, e.g., in terms of consistent terminology. And > this document doesn't seem to reference 3307, which seems incomplete. This is a bigger problem than should be handled in an addressing architecture document. My suggestion is that we work this issue through the IAB's Ad-hoc IPv6 group since they are already focusing on registry clean-up. This can be another sub-bullet on that work list. I think trying to document to IANA that they need to overall a registry in this spec will be too confusing. Regards, Brian --Apple-Mail-3-521923569 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTE2MTgyNzU3WjAjBgkqhkiG9w0B CQQxFgQU0eV2w1eCUKnxe5PapZIA98Xa1OAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAz4jLwpTG0MrHrqXsXGk5aoEmMKisEqWVVs2aJYu96p+s9eLC7vXxbe4HFJpMEcNxBCIU ojalavfos5wCeyRuB8DRK+3LeKm5F/QakfBOlpNo+f8ABR8AL6yU581yzYc/escqlMjBT2NFC0aU FVor3xCO4BBLeFgXxHmdkrCbpRIQ9B8IVRGD9zfnbcqT+TPIbBOowjLPsD5ZNkPj1zTjnU4TGsLf rosPRTzYinVsjxSdd9xwuN7Uo8xggeDmZE08OsUWd6Z3qoxI8Nbb9YheIX+2UiOgfil1iRt/Oh+O JkDxxCxCFCM/JrxWfrc78VSTX9UTQGKf1KU3aQyT4PZWwwAAAAAAAA== --Apple-Mail-3-521923569-- --===============0029605042== 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 -------------------------------------------------------------------- --===============0029605042==-- From ipv6-bounces@ietf.org Mon May 16 14:51:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkgE-0004LH-I9; Mon, 16 May 2005 14:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkgB-0004L1-5m for ipv6@megatron.ietf.org; Mon, 16 May 2005 14:51:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22954 for ; Mon, 16 May 2005 14:51:01 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXkwm-0008Mx-1h for ipv6@ietf.org; Mon, 16 May 2005 15:08:12 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j4GIor9x026240; Mon, 16 May 2005 14:50:53 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08835; Mon, 16 May 2005 14:50:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 May 2005 14:50:52 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0B4542CC@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Brian Haberman'" Date: Mon, 16 May 2005 14:50:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Margaret Wasserman , Thomas Narten , ipv6@ietf.org Subject: RE: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 --> -----Original Message----- --> From: ipv6-bounces@ietf.org --> [mailto:ipv6-bounces@ietf.org]On Behalf Of --> Brian Haberman --> Sent: Monday, May 16, 2005 2:28 PM --> To: Thomas Narten --> Cc: Margaret Wasserman; ipv6@ietf.org --> Subject: Re: last minute review of --> draft-ietf-ipv6-addr-arch-v4-03.txt --> --> Hi Thomas, --> --> On May 12, 2005, at 12:50, Thomas Narten wrote: --> --> > I know this is late, but better late than never... --> > --> > Overall, the document is good, but I think that the document would --> > benefit from slight tweaking w.r.t. to multicast. I.e., I assume that --> > an "addressing architecture" should be complete and at a minimum offer --> > pointers to the relevant pieces. I don't think it quite does that in --> > the case of multicast. --> > --> >> 2.7 Multicast Addresses --> > --> > This section only mentions the T flag, and not the P flag. That doesnt --> > seem right, since the P flag is clearly in use now and not "0". Was --> > there a concern about a possible normative reference? I don't think --> > there needs to be. Suggestion: --> > --> > Old: --> >> +-+-+-+-+ --> >> flgs is a set of 4 flags: |0|0|0|T| --> >> +-+-+-+-+ --> > --> > New: --> > --> > +-+-+-+-+ --> > flgs is a set of 4 flags: |0|0|P|T| --> > +-+-+-+-+ --> > --> > and then add something like: --> > --> > The definition and use of the P bit can be found in [RFC 3307]. --> > --> > and make the reference informative. --> --> Bob and I discussed this and he will be putting text together that --> clarifies the bits with informative references to RFC 3306 (not 3307) --> and RFC 3956. --> --> > --> > Also, there are no IANA considerations for multicast addresses. But, --> > if you look at the IANA web page --> > (http://www.iana.org/assignments/ipv6-multicast-addresses), it says: --> > --> >> IPv6 multicast addresses are defined in "IP Version 6 Addressing --> >> Architecture" [RFC2373]. This defines fixed scope and variable scope --> >> multicast addresses. --> > --> > But, this document doesn't use the terminology "fixed" or "variable" --> > scope. So things seem out of alignment. Does this document need to --> > straighten things out? --> > --> > Or, maybe it's the case that RFC 3307 is (now) the definitive --> > document? (IANA doesn't seem to have picked up anything from --> > there...). But 3307 document doesn't seem to use the "fixed/variable" --> > terminoligy either. --> > --> > So, it's not immediately clear to me what is needed to get the IANA --> > page cleaned up, but since it _might_ involve tweaking text in this --> > document, I think it would be good to understand what needs to be --> > done before approving this document. --> > --> > It's also not immediately clear to me that this document and rfc 3307 --> > are completely aligned, e.g., in terms of consistent terminology. And --> > this document doesn't seem to reference 3307, which seems incomplete. --> --> This is a bigger problem than should be handled in an addressing --> architecture document. Wouldn't it make sense for this document to at least mention that there is a synchronization error in terminology used by IANA with respect to terminology used in this document? --> --> My suggestion is that we work this issue through the IAB's Ad-hoc IPv6 --> group since they are already focusing on registry clean-up. This can be --> another sub-bullet on that work list. I think trying to document to --> IANA that they need to overall a registry in this spec will be too --> confusing. --> --> Regards, --> Brian --> -------------------------------------------------------------------- --> 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 May 16 15:08:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkx9-0008Jt-J8; Mon, 16 May 2005 15:08:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkx7-0008Jj-PQ for ipv6@megatron.ietf.org; Mon, 16 May 2005 15:08:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25405 for ; Mon, 16 May 2005 15:08:32 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlDi-0000m1-U6 for ipv6@ietf.org; Mon, 16 May 2005 15:25:43 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11747449; Mon, 16 May 2005 15:07:59 -0400 In-Reply-To: <313680C9A886D511A06000204840E1CF0B4542CC@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0B4542CC@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <62cfca8432b6a5d4d7f803900744ea37@innovationslab.net> From: Brian Haberman Date: Mon, 16 May 2005 15:07:57 -0400 To: "Gray, Eric" X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: Margaret Wasserman , Thomas Narten , ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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="===============1100841933==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1100841933== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-524324501; protocol="application/pkcs7-signature" --Apple-Mail-4-524324501 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 16, 2005, at 14:50, Gray, Eric wrote: > > > --> -----Original Message----- > --> From: ipv6-bounces@ietf.org > --> [mailto:ipv6-bounces@ietf.org]On Behalf Of > --> Brian Haberman > --> Sent: Monday, May 16, 2005 2:28 PM > --> To: Thomas Narten > --> Cc: Margaret Wasserman; ipv6@ietf.org > --> Subject: Re: last minute review of > --> draft-ietf-ipv6-addr-arch-v4-03.txt > --> > --> Hi Thomas, > --> > --> On May 12, 2005, at 12:50, Thomas Narten wrote: > --> > --> > I know this is late, but better late than never... > --> > > --> > Overall, the document is good, but I think that the document > would > --> > benefit from slight tweaking w.r.t. to multicast. I.e., I assume > that > --> > an "addressing architecture" should be complete and at a minimum > offer > --> > pointers to the relevant pieces. I don't think it quite does > that in > --> > the case of multicast. > --> > > --> >> 2.7 Multicast Addresses > --> > > --> > This section only mentions the T flag, and not the P flag. That > doesnt > --> > seem right, since the P flag is clearly in use now and not "0". > Was > --> > there a concern about a possible normative reference? I don't > think > --> > there needs to be. Suggestion: > --> > > --> > Old: > --> >> +-+-+-+-+ > --> >> flgs is a set of 4 flags: |0|0|0|T| > --> >> +-+-+-+-+ > --> > > --> > New: > --> > > --> > +-+-+-+-+ > --> > flgs is a set of 4 flags: |0|0|P|T| > --> > +-+-+-+-+ > --> > > --> > and then add something like: > --> > > --> > The definition and use of the P bit can be found in [RFC > 3307]. > --> > > --> > and make the reference informative. > --> > --> Bob and I discussed this and he will be putting text together that > --> clarifies the bits with informative references to RFC 3306 (not > 3307) > --> and RFC 3956. > --> > --> > > --> > Also, there are no IANA considerations for multicast addresses. > But, > --> > if you look at the IANA web page > --> > (http://www.iana.org/assignments/ipv6-multicast-addresses), it > says: > --> > > --> >> IPv6 multicast addresses are defined in "IP Version 6 Addressing > --> >> Architecture" [RFC2373]. This defines fixed scope and variable > scope > --> >> multicast addresses. > --> > > --> > But, this document doesn't use the terminology "fixed" or > "variable" > --> > scope. So things seem out of alignment. Does this document need > to > --> > straighten things out? > --> > > --> > Or, maybe it's the case that RFC 3307 is (now) the definitive > --> > document? (IANA doesn't seem to have picked up anything from > --> > there...). But 3307 document doesn't seem to use the > "fixed/variable" > --> > terminoligy either. > --> > > --> > So, it's not immediately clear to me what is needed to get the > IANA > --> > page cleaned up, but since it _might_ involve tweaking text in > this > --> > document, I think it would be good to understand what needs to > be > --> > done before approving this document. > --> > > --> > It's also not immediately clear to me that this document and rfc > 3307 > --> > are completely aligned, e.g., in terms of consistent > terminology. And > --> > this document doesn't seem to reference 3307, which seems > incomplete. > --> > --> This is a bigger problem than should be handled in an addressing > --> architecture document. > > Wouldn't it make sense for this document to at least mention that > there is a synchronization error in terminology used by IANA with > respect to terminology used in this document? Personally, I don't think so. The addressing architecture actually points at RFC 2375 which doesn't say anything about the allocation rules for IANA. RFC 3307 does put forth the rules. So, the cleanup needs to ensure that 3307 is the definitive reference for the registry. It seems to be an in-direct approach to say something about 3307 in the new addressing architecture. As for the terminology, the text in the new addressing architecture is the correct text (in my view). The IANA pages will be updated to reflect that once it is published. Additionally, the ad-hoc committee can do this without being dependent on the approval/publication of a document. We can point IANA to 3307 and say it is the guidelines for all multicast addresses and then work with them to ensure the webpages are correct. Regards, Brian --Apple-Mail-4-524324501 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTE2MTkwNzU4WjAjBgkqhkiG9w0B CQQxFgQUbg2aOob5ap4Ijibe2uflSg7uyq0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEALjLkn/4cmymT0Sf52cfMw6ixbVh6V9KpkLFaWzFXHWszQ0BNhnByudkf4HPE/JAtfyjD nTeX+ASA6h6LMk8qZozRjg/MhYBk1CH+ooN6Uj0lng1EakHITgxQ/XLEuv2PG4qXiYFmqrAayEa9 Pl8njhyA01iNJ8N96Kx3RO/MZDMHLV1UKAmB72u6O/D+CXVDDEkjuFnW8vFmhptvWOGoE6fjLIPH C6Z3lro9qbEPlbNIaScL7wGbsThvRFJo2QmdPndBCWhwYAD96r6oTjgM8ublHJkSvWslULNiEnrL /ZPVMmslvZMmDvmfIHHvHmAUBBnYPk4fUamDK3QkkG6kRAAAAAAAAA== --Apple-Mail-4-524324501-- --===============1100841933== 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 -------------------------------------------------------------------- --===============1100841933==-- From ipv6-bounces@ietf.org Mon May 16 15:11:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkzr-0000Bg-BC; Mon, 16 May 2005 15:11:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkzp-0000Bb-H8 for ipv6@megatron.ietf.org; Mon, 16 May 2005 15:11:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25961 for ; Mon, 16 May 2005 15:11:19 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlGQ-0000rQ-Mp for ipv6@ietf.org; Mon, 16 May 2005 15:28:31 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j4GJB89x026698; Mon, 16 May 2005 15:11:08 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA11663; Mon, 16 May 2005 15:11:08 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 May 2005 15:11:07 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0B4542CD@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Brian Haberman'" , "Gray, Eric" Date: Mon, 16 May 2005 15:11:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Margaret Wasserman , Thomas Narten , ipv6@ietf.org Subject: RE: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 Fair enough. --> -----Original Message----- --> From: Brian Haberman [mailto:brian@innovationslab.net] --> Sent: Monday, May 16, 2005 3:08 PM --> To: Gray, Eric --> Cc: ipv6@ietf.org; Margaret Wasserman; Thomas Narten --> Subject: Re: last minute review of --> draft-ietf-ipv6-addr-arch-v4-03.txt --> --> --> --> On May 16, 2005, at 14:50, Gray, Eric wrote: --> --> > --> > --> > --> -----Original Message----- --> > --> From: ipv6-bounces@ietf.org --> > --> [mailto:ipv6-bounces@ietf.org]On Behalf Of --> > --> Brian Haberman --> > --> Sent: Monday, May 16, 2005 2:28 PM --> > --> To: Thomas Narten --> > --> Cc: Margaret Wasserman; ipv6@ietf.org --> > --> Subject: Re: last minute review of --> > --> draft-ietf-ipv6-addr-arch-v4-03.txt --> > --> --> > --> Hi Thomas, --> > --> --> > --> On May 12, 2005, at 12:50, Thomas Narten wrote: --> > --> --> > --> > I know this is late, but better late than never... --> > --> > --> > --> > Overall, the document is good, but I think that the --> document --> > would --> > --> > benefit from slight tweaking w.r.t. to multicast. --> I.e., I assume --> > that --> > --> > an "addressing architecture" should be complete and --> at a minimum --> > offer --> > --> > pointers to the relevant pieces. I don't think it --> quite does --> > that in --> > --> > the case of multicast. --> > --> > --> > --> >> 2.7 Multicast Addresses --> > --> > --> > --> > This section only mentions the T flag, and not the --> P flag. That --> > doesnt --> > --> > seem right, since the P flag is clearly in use now --> and not "0". --> > Was --> > --> > there a concern about a possible normative --> reference? I don't --> > think --> > --> > there needs to be. Suggestion: --> > --> > --> > --> > Old: --> > --> >> +-+-+-+-+ --> > --> >> flgs is a set of 4 flags: |0|0|0|T| --> > --> >> +-+-+-+-+ --> > --> > --> > --> > New: --> > --> > --> > --> > +-+-+-+-+ --> > --> > flgs is a set of 4 flags: |0|0|P|T| --> > --> > +-+-+-+-+ --> > --> > --> > --> > and then add something like: --> > --> > --> > --> > The definition and use of the P bit can be --> found in [RFC --> > 3307]. --> > --> > --> > --> > and make the reference informative. --> > --> --> > --> Bob and I discussed this and he will be putting text --> together that --> > --> clarifies the bits with informative references to RFC --> 3306 (not --> > 3307) --> > --> and RFC 3956. --> > --> --> > --> > --> > --> > Also, there are no IANA considerations for --> multicast addresses. --> > But, --> > --> > if you look at the IANA web page --> > --> > --> (http://www.iana.org/assignments/ipv6-multicast-addresses), it --> > says: --> > --> > --> > --> >> IPv6 multicast addresses are defined in "IP --> Version 6 Addressing --> > --> >> Architecture" [RFC2373]. This defines fixed scope --> and variable --> > scope --> > --> >> multicast addresses. --> > --> > --> > --> > But, this document doesn't use the terminology "fixed" or --> > "variable" --> > --> > scope. So things seem out of alignment. Does this --> document need --> > to --> > --> > straighten things out? --> > --> > --> > --> > Or, maybe it's the case that RFC 3307 is (now) the --> definitive --> > --> > document? (IANA doesn't seem to have picked up --> anything from --> > --> > there...). But 3307 document doesn't seem to use the --> > "fixed/variable" --> > --> > terminoligy either. --> > --> > --> > --> > So, it's not immediately clear to me what is needed --> to get the --> > IANA --> > --> > page cleaned up, but since it _might_ involve --> tweaking text in --> > this --> > --> > document, I think it would be good to understand --> what needs to --> > be --> > --> > done before approving this document. --> > --> > --> > --> > It's also not immediately clear to me that this --> document and rfc --> > 3307 --> > --> > are completely aligned, e.g., in terms of consistent --> > terminology. And --> > --> > this document doesn't seem to reference 3307, which seems --> > incomplete. --> > --> --> > --> This is a bigger problem than should be handled in an --> addressing --> > --> architecture document. --> > --> > Wouldn't it make sense for this document to at least mention that --> > there is a synchronization error in terminology used by IANA with --> > respect to terminology used in this document? --> --> Personally, I don't think so. The addressing architecture actually --> points --> at RFC 2375 which doesn't say anything about the allocation rules --> for IANA. RFC 3307 does put forth the rules. So, the cleanup needs --> to ensure that 3307 is the definitive reference for the --> registry. It --> seems --> to be an in-direct approach to say something about 3307 in the new --> addressing architecture. --> --> As for the terminology, the text in the new addressing --> architecture is --> the correct text (in my view). The IANA pages will be updated to --> reflect that once it is published. --> --> Additionally, the ad-hoc committee can do this without --> being dependent --> on the approval/publication of a document. We can point --> IANA to 3307 --> and say it is the guidelines for all multicast addresses --> and then work --> with them to ensure the webpages are correct. --> --> Regards, --> Brian --> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 16:02:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlnI-0008Rs-G6; Mon, 16 May 2005 16:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlnG-0008LH-Ib for ipv6@megatron.ietf.org; Mon, 16 May 2005 16:02:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06957 for ; Mon, 16 May 2005 16:02:22 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXm3o-0004zw-QO for ipv6@ietf.org; Mon, 16 May 2005 16:19:33 -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 j4GK2CgV010023 for ; Mon, 16 May 2005 16:02:12 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4GK2CXn121346 for ; Mon, 16 May 2005 16:02:12 -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 j4GK2Cc1009192 for ; Mon, 16 May 2005 16:02:12 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4GK2Bb3009134; Mon, 16 May 2005 16:02:11 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4GK2AoL020162; Mon, 16 May 2005 16:02:10 -0400 Message-Id: <200505162002.j4GK2AoL020162@rotala.raleigh.ibm.com> To: Brian Haberman In-Reply-To: Message from brian@innovationslab.net of "Mon, 16 May 2005 15:07:57 EDT." <62cfca8432b6a5d4d7f803900744ea37@innovationslab.net> Date: Mon, 16 May 2005 16:02:10 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 Brian. > > Wouldn't it make sense for this document to at least mention that > > there is a synchronization error in terminology used by IANA with > > respect to terminology used in this document? > Personally, I don't think so. The addressing architecture actually > points at RFC 2375 which doesn't say anything about the allocation > rules for IANA. RFC 3307 does put forth the rules. So, the cleanup > needs to ensure that 3307 is the definitive reference for the > registry. It seems to be an in-direct approach to say something > about 3307 in the new addressing architecture. > As for the terminology, the text in the new addressing architecture > is the correct text (in my view). The IANA pages will be updated to > reflect that once it is published. I'm still trying to convince myself that this is the case. addr-arch has the T bit to distinguish between: > T = 0 indicates a permanently-assigned ("well-known") > multicast address, assigned by the Internet Assigned Number > Authority (IANA). > > T = 1 indicates a non-permanently-assigned ("transient") But, RFC 3307 (which has the IANA considerations for mcast addresses) doesn't use the latter terminology. It uses: > - The range 0x80000000 to 0xFFFFFFFF is reserved for use by > dynamic multicast address allocation mechanisms, see Section > 4.3. I.e., "dynamic". This may be a minor point, but in looking through the various documents, this use of different terms didn't help me figure out what was going on... Which terminology is preferred? Is it the text in RFC 3307, or the text in addr-arch? > Additionally, the ad-hoc committee can do this without being dependent > on the approval/publication of a document. We can point IANA to 3307 > and say it is the guidelines for all multicast addresses and then work > with them to ensure the webpages are correct. I think this works as long as what we are asking IANA to do is consistent with the existing documents, as the ad-hoc shouldn't be filling in the gaps on its own. Or, if it needs to, then a document would presumably need to be produced and pushed through the system. I hope we don't need another (separate) document. Also, one thing I notice (not sure how to fix or whether to fix) is that RFC 3307 talks about "group IDs", which seem to be 4-byte quantities (per 3307): > 4.2 Permanent IPv6 Multicast Group Identifiers > > Permanent group IDs allow for a global identifier of a particular > service (e.g. Network Time Protocol (NTP) being assigned the group ID > 0x40404040). The use of permanent group IDs differs from permanent > multicast addresses in that a permanent group ID offers a global > identifier for a service being offered by numerous servers. > > As an example, consider the NTP example group ID of 0x40404040. An > NTP client would be able to access multiple servers and multiple > scopes. That is, the NTP client will know that the group ID > 0x40404040 identifies an NTP multicast stream regardless of the upper > 96 bits of the multicast address. > > Permanent group IDs are allocated on an Expert Review basis, in the > range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant > to be used in IPv6 multicast addresses, defined in [UNIMCAST]. But, addr-arch talks about "group IDs" differently: > | 8 | 4 | 4 | 112 bits | > +------ -+----+----+---------------------------------------------+ > |11111111|flgs|scop| group ID | > +--------+----+----+---------------------------------------------+ i.e., they are 112-bits long. And there is no mention of the RFC 3307-style Group IDs for which IANA has created a registry. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 16: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 1DXm2s-0002qN-6A; Mon, 16 May 2005 16: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 1DXm2q-0002pk-7v for ipv6@megatron.ietf.org; Mon, 16 May 2005 16:18:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14388 for ; Mon, 16 May 2005 16:18:25 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmJK-0007mO-8A for ipv6@ietf.org; Mon, 16 May 2005 16:35:36 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4GKI8mD544528 for ; Mon, 16 May 2005 16:18:08 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4GKI8Gc236254 for ; Mon, 16 May 2005 14:18:08 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4GKI7tO029955 for ; Mon, 16 May 2005 14:18:07 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4GKI7xe029912; Mon, 16 May 2005 14:18:07 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4GKI5S5020274; Mon, 16 May 2005 16:18:06 -0400 Message-Id: <200505162018.j4GKI5S5020274@rotala.raleigh.ibm.com> To: "Gray, Eric" In-Reply-To: Message from Eric.Gray@marconi.com of "Mon, 16 May 2005 14:50:51 EDT." <313680C9A886D511A06000204840E1CF0B4542CC@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 16 May 2005 16:18:05 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Margaret Wasserman , 'Brian Haberman' , ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 > Wouldn't it make sense for this document to at least mention that > there is a synchronization error in terminology used by IANA with > respect to terminology used in this document? I agree that if there is a synchronization issue between IANA and our docs, and our docs are correct, there is no need to mention that in addr-arch. We can straighten things out via email. But before approving addr-arch, I think we should be reasonably confident there is nothing else in that document we want to tweak in order get the pages the way we want them. Somewhat related, I think it would be helpful to add something like the following to the IANA considerations for addr arch (which is effectively empty at the moment w.r.t. to allocation issues): IANA considerations for the management of global unicast address space can be found in [RFC 3513] and are not updated by this document. IANA considerations for the management of IPv6 multicast address space can be found in [RFC 3307] and are not updated by this document. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 16:30:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmEX-0004pn-KU; Mon, 16 May 2005 16:30:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmES-0004pZ-PW for ipv6@megatron.ietf.org; Mon, 16 May 2005 16:30:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16633 for ; Mon, 16 May 2005 16:30:30 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmV4-0000Gd-L5 for ipv6@ietf.org; Mon, 16 May 2005 16:47:43 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11751096; Mon, 16 May 2005 16:26:41 -0400 In-Reply-To: <200505162002.j4GK2AoL020162@rotala.raleigh.ibm.com> References: <200505162002.j4GK2AoL020162@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: Brian Haberman Date: Mon, 16 May 2005 16:26:39 -0400 To: Thomas Narten X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Margaret Wasserman , ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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="===============1974894783==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1974894783== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-529046440; protocol="application/pkcs7-signature" --Apple-Mail-6-529046440 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Thomas, On May 16, 2005, at 16:02, Thomas Narten wrote: > Hi Brian. > >>> Wouldn't it make sense for this document to at least mention that >>> there is a synchronization error in terminology used by IANA with >>> respect to terminology used in this document? > >> Personally, I don't think so. The addressing architecture actually >> points at RFC 2375 which doesn't say anything about the allocation >> rules for IANA. RFC 3307 does put forth the rules. So, the cleanup >> needs to ensure that 3307 is the definitive reference for the >> registry. It seems to be an in-direct approach to say something >> about 3307 in the new addressing architecture. > >> As for the terminology, the text in the new addressing architecture >> is the correct text (in my view). The IANA pages will be updated to >> reflect that once it is published. > > I'm still trying to convince myself that this is the case. > > addr-arch has the T bit to distinguish between: > >> T = 0 indicates a permanently-assigned ("well-known") >> multicast address, assigned by the Internet Assigned >> Number >> Authority (IANA). >> >> T = 1 indicates a non-permanently-assigned ("transient") > > But, RFC 3307 (which has the IANA considerations for mcast addresses) > doesn't use the latter terminology. It uses: > >> - The range 0x80000000 to 0xFFFFFFFF is reserved for use by >> dynamic multicast address allocation mechanisms, see Section >> 4.3. > > I.e., "dynamic". This may be a minor point, but in looking through the > various documents, this use of different terms didn't help me figure > out what was going on... As I mentioned, Bob will be updating the addressing arch to incorporate text to clarify the R & P bits. We will ensure that the language is consistent. With the use of "dynamic" or "transient" in the IANA section, the text from Section 4.3 in 3307 says: Dynamic IPv6 multicast addresses can be allocated by an allocation server or by an end-host. Regardless of the allocation mechanism, all dynamically allocated IPv6 multicast addresses MUST have the T bit set to 1. This was done to tie together the terminology from the IPv6 architecture with the multicast address allocation language in the MALLOC work. So, it really tries to manage two sets of definitions. > > Which terminology is preferred? Is it the text in RFC 3307, or the > text in addr-arch? Depends on whether you want to talk IPv6 or MALLOC. :) Seriously, 3307 does suffer from the fact it straddles two worlds that defined separate terminology for the same behavior. > >> Additionally, the ad-hoc committee can do this without being dependent >> on the approval/publication of a document. We can point IANA to 3307 >> and say it is the guidelines for all multicast addresses and then work >> with them to ensure the webpages are correct. > > I think this works as long as what we are asking IANA to do is > consistent with the existing documents, as the ad-hoc shouldn't be > filling in the gaps on its own. Or, if it needs to, then a document > would presumably need to be produced and pushed through the system. > > I hope we don't need another (separate) document. As do I. My opinion is that we will need to spend some time explaining the existing docs rather than writing yet another one. > > Also, one thing I notice (not sure how to fix or whether to fix) is > that RFC 3307 talks about "group IDs", which seem to be 4-byte > quantities (per 3307): > >> 4.2 Permanent IPv6 Multicast Group Identifiers >> >> Permanent group IDs allow for a global identifier of a particular >> service (e.g. Network Time Protocol (NTP) being assigned the group >> ID >> 0x40404040). The use of permanent group IDs differs from permanent >> multicast addresses in that a permanent group ID offers a global >> identifier for a service being offered by numerous servers. >> >> As an example, consider the NTP example group ID of 0x40404040. An >> NTP client would be able to access multiple servers and multiple >> scopes. That is, the NTP client will know that the group ID >> 0x40404040 identifies an NTP multicast stream regardless of the >> upper >> 96 bits of the multicast address. >> >> Permanent group IDs are allocated on an Expert Review basis, in the >> range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are >> meant >> to be used in IPv6 multicast addresses, defined in [UNIMCAST]. > > But, addr-arch talks about "group IDs" differently: > >> | 8 | 4 | 4 | 112 bits | >> +------ -+----+----+---------------------------------------------+ >> |11111111|flgs|scop| group ID | >> +--------+----+----+---------------------------------------------+ > > i.e., they are 112-bits long. And there is no mention of the RFC > 3307-style Group IDs for which IANA has created a registry. RFC 3306 explains this difference. So, the additional reference to 3306 for the P bit will help with this. Regards, Brian --Apple-Mail-6-529046440 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTE2MjAyNjQwWjAjBgkqhkiG9w0B CQQxFgQU/6GEf3+0S8SIHcUmdm083fKAZssweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAE12KXDGzBCGbu1DkDZCoukHPwBm7+cso4TJo57LHXQWUrIOJFBTO0oI9qnjVcoT29kG/ C4Z6LnALLmkTzfjwqEy1uL1hI0ibLr0EdiY9Sm/WXgwpD63jz8dqZNJLXvA3rqr+oosRUroCQOEr qKYcVMqD59OBr10Igw8lWtkchLUgdArH4oXyXeLqNp1Qs1q8g/O4il2D5sh7gqZQKYJ2PWxEilPV JU46jkaoMeImYNynZXG4bWSYMBdEdAtB/OQ11eFtVlsffjCZxrIpQ8KstA+9OEnqHlN8gCMgAMzu WgTUXGjvYzhSk0goxjvDxsA7lqd8y6EXiLTMZZRcMBWb6QAAAAAAAA== --Apple-Mail-6-529046440-- --===============1974894783== 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 -------------------------------------------------------------------- --===============1974894783==-- From ipv6-bounces@ietf.org Mon May 16 16:34:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmI7-0005Ok-9b; Mon, 16 May 2005 16:34:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmI5-0005OE-FW for ipv6@megatron.ietf.org; Mon, 16 May 2005 16:34:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17141 for ; Mon, 16 May 2005 16:34:15 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmYg-0000Q6-Fc for ipv6@ietf.org; Mon, 16 May 2005 16:51:27 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4GKY3hk021808 for ; Mon, 16 May 2005 16:34:03 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4GKY3Xn092050 for ; Mon, 16 May 2005 16:34:03 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4GKY2ZH027457 for ; Mon, 16 May 2005 16:34:03 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4GKY2mN027447; Mon, 16 May 2005 16:34:02 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4GKY2PU020376; Mon, 16 May 2005 16:34:02 -0400 Message-Id: <200505162034.j4GKY2PU020376@rotala.raleigh.ibm.com> To: Brian Haberman In-Reply-To: Message from brian@innovationslab.net of "Mon, 16 May 2005 16:26:39 EDT." Date: Mon, 16 May 2005 16:34:02 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 > As I mentioned, Bob will be updating the addressing arch to incorporate > text to clarify the R & P bits. We will ensure that the language is > consistent. Sounds good. I guess the thing to do now is see what the proposed text says. Thanks, Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 17:10:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmqo-0007nI-HR; Mon, 16 May 2005 17:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXmql-0007n8-DA; Mon, 16 May 2005 17:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20865; Mon, 16 May 2005 17:10:04 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXn7M-0002GS-B7; Mon, 16 May 2005 17:27:17 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4GL8Wf31311; Tue, 17 May 2005 00:08:32 +0300 Date: Tue, 17 May 2005 00:08:32 +0300 (EEST) From: Pekka Savola To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> Message-ID: References: <8E296595B6471A4689555D5D725EBB212B347C@xmb-rtp-20a.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Mon, 16 May 2005, Bernie Volz (volz) wrote: > BTW, if you want to look at this from the router administrator's > perspective: > > Configure the router to send the M flag set in routing advertisements > for a Link IF: > 1. A stateful DHCP server is deployed for that link (either on it or > reachable via a relay agent) AND IMHO, you're making a significant leap of faith in assuming that whoever configures the router's M-flag advertisements has sufficient clue to grasp the different semantics that arise with: - M-flag and/or O-flag - stateless and stateful clients - stateless and stateful servers - stateless and stateful relay agents Hence, if we want to build a robust system, we need to design it with care. -- 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 May 16 17:21:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXn1l-0002Ky-VX; Mon, 16 May 2005 17:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXn1k-0002Kq-K7; Mon, 16 May 2005 17:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21832; Mon, 16 May 2005 17:21:26 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXnIL-0002kH-SX; Mon, 16 May 2005 17:38:39 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 May 2005 17:35:50 -0400 X-IronPort-AV: i="3.93,112,1115006400"; d="scan'208"; a="49662067:sNHT2837838494" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4GLJCni012488; Mon, 16 May 2005 17:20:00 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 17:19:59 -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: Mon, 16 May 2005 17:19:59 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3553@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVaW85E7las8HC2Qs2YF0DjHsb1NgAAPbwg From: "Bernie Volz \(volz\)" To: "Pekka Savola" X-OriginalArrivalTime: 16 May 2005 21:19:59.0948 (UTC) FILETIME=[043CD0C0:01C55A5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Hey, if they don't know what they're doing then set the bits and be done with it. If there's no DHCP server, the clients will try to get configuration information and fail and continuously try in the background. That's the safest fallback and the recommended default, IMHO. If they do set them wrong, it won't take long for users to complain. Just as they do now if the DHCP server or routing infrastructure is down. Trying to design for stupidity only produces the same. - Bernie=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Monday, May 16, 2005 5:09 PM > To: Bernie Volz (volz) > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph=20 > Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > BTW, if you want to look at this from the router administrator's > > perspective: > > > > Configure the router to send the M flag set in routing=20 > advertisements > > for a Link IF: > > 1. A stateful DHCP server is deployed for that link (either on it or > > reachable via a relay agent) AND >=20 > IMHO, you're making a significant leap of faith in assuming that=20 > whoever configures the router's M-flag advertisements has sufficient=20 > clue to grasp the different semantics that arise with: >=20 > - M-flag and/or O-flag > - stateless and stateful clients > - stateless and stateful servers > - stateless and stateful relay agents >=20 > Hence, if we want to build a robust system, we need to design it with=20 > care. >=20 >=20 >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 19:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXpLv-0008Kq-CW; Mon, 16 May 2005 19:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXpLr-0008KC-3C for ipv6@megatron.ietf.org; Mon, 16 May 2005 19:50:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17430 for ; Mon, 16 May 2005 19:50:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXpcT-0004ff-M4 for ipv6@ietf.org; Mon, 16 May 2005 20:07:35 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4GNJ5f01371; Mon, 16 May 2005 16:19:05 -0700 X-mProtect: <200505162319> Nokia Silicon Valley Messaging Protection Received: from danira-pool055246.americas.nokia.com (10.241.55.246, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd9dRMag; Mon, 16 May 2005 16:19:03 PDT Message-Id: <6.2.1.2.2.20050516151813.02d01e78@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 16 May 2005 16:49:56 -0700 To: Thomas Narten From: Bob Hinden In-Reply-To: <200505162018.j4GKI5S5020274@rotala.raleigh.ibm.com> References: <200505162018.j4GKI5S5020274@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 Thomas, >Somewhat related, I think it would be helpful to add something like the >following to the IANA considerations for addr arch (which is >effectively empty at the moment w.r.t. to allocation issues): > > IANA considerations for the management of global unicast address > space can be found in [RFC 3513] and are not updated by this > document. > > IANA considerations for the management of IPv6 multicast address > space can be found in [RFC 3307] and are not updated by this > document. This raises the question I have had for a while, is when doing updates to existing standard what to put in the IANA section. It seems to me it should be what changes should be made to the IANA registries, not a complete copy. This is very different from the technical content of the document. [I am starting to wonder if IANA considerations really belong in RFCs, but lets not go there today :-) ] Instead of what you suggested, I think something like the following would be better: No other IANA IPv6 address registries need to be changed based on this document. A few reasons for this include the references to 3513 and 3307 doesn't capture the complete history of the current IANA registries and this document will obsolete 3513 and this might make the note confusing. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 20:59:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXqQI-0002oS-8N; Mon, 16 May 2005 20:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXqQG-0002oB-8I for ipv6@megatron.ietf.org; Mon, 16 May 2005 20:59:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22020 for ; Mon, 16 May 2005 20:58:56 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXqgs-00087p-A2 for ipv6@ietf.org; Mon, 16 May 2005 21:16:10 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4H0wlua451494 for ; Mon, 16 May 2005 20:58:48 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4H0wlGc236278 for ; Mon, 16 May 2005 18:58:47 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4H0wlsP004188 for ; Mon, 16 May 2005 18:58:47 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-118.mts.ibm.com [9.65.234.118]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4H0wkYI004181; Mon, 16 May 2005 18:58:46 -0600 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 j4H0vTEE005773; Mon, 16 May 2005 20:57:29 -0400 Message-Id: <200505170057.j4H0vTEE005773@cichlid.raleigh.ibm.com> To: Bob Hinden In-Reply-To: Message from Bob Hinden of "Mon, 16 May 2005 16:49:56 PDT." <6.2.1.2.2.20050516151813.02d01e78@mailhost.iprg.nokia.com> Date: Mon, 16 May 2005 20:57:29 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 Bob, > This raises the question I have had for a while, is when doing updates to > existing standard what to put in the IANA section. It seems to me it > should be what changes should be made to the IANA registries, not a > complete copy. This is very different from the technical content of the > document. Yep. And I don't have a one-size-fits all answer. I've seen some documents just repeat the old section, but as you note that reads funny if IANA has already done the work. And since this document is obsoleting RFC 3513, it seems odd to point back to it for definitive text. I'm not sure the IESG has thought in a lot of detail about the significance of obsoleting a document that contains an IANA considerations section. But, having said that, when trying to find the IANA considerations related to a name space, it can be rather interesting sometimes just trying to track down the pointers. So, I prefer seeing at least some pointers to other documents than nothing at all. My wording was an attempt to provide at least the start of a reference, while still making it clear that this document isn't changing any of the rules that are already in place. > Instead of what you suggested, I think something like the following would > be better: > No other IANA IPv6 address registries need to be changed based on > this document. For me, having a reference to other documents is really the purpose of adding something to this section. The above doesn't really add much beyond complete silence. > A few reasons for this include the references to 3513 and 3307 doesn't > capture the complete history of the current IANA registries and this > document will obsolete 3513 and this might make the note confusing. Another possibility is to include some (but perhaps not the entire table) from RFC 3513, but point out that the new text is being included for completeness and doesn't establish any new policy. That might be a better the referring to an obsoleted document. What I was trying to achieve was a balance between repeating all the history (which is sometimes a bit convoluted) with at least a pointer on where to get started for the details. But maybe we shouldn't even go here... :-( Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 16 22: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 1DXrNI-0001Hq-8N; Mon, 16 May 2005 22: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 1DXrNG-0001Hi-EW; Mon, 16 May 2005 21:59:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27324; Mon, 16 May 2005 21:59:56 -0400 (EDT) Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXrdq-0002v8-Ur; Mon, 16 May 2005 22:17:11 -0400 Received: from S018431 ([141.154.125.12]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGM00DL42VR16Y2@vms042.mailsrvcs.net>; Mon, 16 May 2005 20:59:52 -0500 (CDT) Date: Mon, 16 May 2005 21:59:49 -0400 From: "timothy enos" In-reply-to: <8E296595B6471A4689555D5D725EBB212B3553@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz \(volz\)'" , "'Pekka Savola'" Message-id: <001401c55a84$1c246fa0$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: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'JINMEI Tatuya / ????' , 'IPv6 WG' , "'Ralph Droms \(rdroms\)'" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Bernie, Your points are well taken, and I agree. Making these flags 'hints' makes sense. Also, it seems that if a client does not know what to do (forgive the anthropomorphism) in response to having received an RA with the M (and O) bit(s) set (because it is not a DHCPv6 client), it would just ignore it/them. Also wondering if there are any RFC 3315-capable clients that, after failing to get config info from a DHCPv6 server 'x' times, would revert to SLAC? Tim Enos 1Sam16:7 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, May 16, 2005 5:20 PM To: Pekka Savola Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Hey, if they don't know what they're doing then set the bits and be done with it. If there's no DHCP server, the clients will try to get configuration information and fail and continuously try in the background. That's the safest fallback and the recommended default, IMHO. If they do set them wrong, it won't take long for users to complain. Just as they do now if the DHCP server or routing infrastructure is down. Trying to design for stupidity only produces the same. - Bernie > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, May 16, 2005 5:09 PM > To: Bernie Volz (volz) > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph > Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > BTW, if you want to look at this from the router administrator's > > perspective: > > > > Configure the router to send the M flag set in routing > advertisements > > for a Link IF: > > 1. A stateful DHCP server is deployed for that link (either on it or > > reachable via a relay agent) AND > > IMHO, you're making a significant leap of faith in assuming that > whoever configures the router's M-flag advertisements has sufficient > clue to grasp the different semantics that arise with: > > - M-flag and/or O-flag > - stateless and stateful clients > - stateless and stateful servers > - stateless and stateful relay agents > > Hence, if we want to build a robust system, we need to design it with > care. > > > > -- > 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 17 01:50:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXuyn-0001bO-QB; Tue, 17 May 2005 01:50:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXuym-0001bJ-PR for ipv6@megatron.ietf.org; Tue, 17 May 2005 01:50:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20011 for ; Tue, 17 May 2005 01:50:55 -0400 (EDT) Received: from dontaku.fit.ac.jp ([150.43.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXvFS-00078o-IV for ipv6@ietf.org; Tue, 17 May 2005 02:08:11 -0400 Received: from dontaku.fit.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.fit.ac.jp (Postfix) with ESMTP id 3CC7914C019 for ; Tue, 17 May 2005 14:50:39 +0900 (JST) Received: from [150.43.233.162] (nausica.ce.fit.ac.jp [150.43.233.162]) by dontaku.fit.ac.jp (Postfix) with ESMTP id 1DA0F14C026 for ; Tue, 17 May 2005 14:50:39 +0900 (JST) Message-ID: <428985A7.2050403@unisa.it> Date: Tue, 17 May 2005 14:48:23 +0900 From: giuseppe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: DAD 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 IPv6 stateless address autoconfiguration, how is it possible that the generated address could be duplicated? The MAC that host appends to the link prefix is unique, isn't it? Replies appreciated G -- ---------------------- ---------------------- Giuseppe De Marco, Ph.D. Dipartimento di Ingegneria dell'Informazione e Ingegneria Elettrica DIIIE, University of Salerno via ponte don Melillo 1, Fisciano, Salerno tel: +39 089 964012 email: gdemarco@unisa.it Department of Information and Communication Engineering Faculty of Information Engineering Fukuoka Institute of Technology (FIT) 3-30-1 Wajiro-Higashi, Higashi-ku, Fukuoka 811-0295 Japan email: demarco@fit.ac.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 May 17 01:59:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXv6k-0003ne-5J; Tue, 17 May 2005 01:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXv6i-0003nS-6I for ipv6@megatron.ietf.org; Tue, 17 May 2005 01:59:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20871 for ; Tue, 17 May 2005 01:59:06 -0400 (EDT) Received: from 27.cust14.sa.dsl.ozemail.com.au ([210.84.237.27] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXvNN-0007Wg-Nz for ipv6@ietf.org; Tue, 17 May 2005 02:16:23 -0400 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 2BA5262AFE; Tue, 17 May 2005 15:28:53 +0930 (CST) Date: Tue, 17 May 2005 15:28:52 +0930 From: Mark Smith To: giuseppe Message-Id: <20050517152852.5f58a941.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <428985A7.2050403@unisa.it> References: <428985A7.2050403@unisa.it> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: DAD 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, 17 May 2005 14:48:23 +0900 giuseppe wrote: > In IPv6 stateless address autoconfiguration, how is it possible that the > generated address could be duplicated? > The MAC that host appends to the link prefix is unique, isn't it? Not necessarily, a mistake could have been made during manufacturer assignment of serial numbers, or a net admin could make a mistake if they choose to use locally assigned MAC addresses. A few examples of this happening were raised on this ML a while back, the thread can be accessed here : http://www.mail-archive.com/ipng@sunroof.eng.sun.com/msg12198.html 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 May 17 07:38:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY0Pb-00007s-Kh; Tue, 17 May 2005 07:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY0PZ-00007f-QD for ipv6@megatron.ietf.org; Tue, 17 May 2005 07:38:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10850 for ; Tue, 17 May 2005 07:38:56 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY0gJ-0000I1-LK for ipv6@ietf.org; Tue, 17 May 2005 07:56:15 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id B0F8420001DF; Tue, 17 May 2005 07:38:40 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 07:38:39 -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, 17 May 2005 07:26:46 -0400 Message-ID: <936A4045C332714F975800409DE092403F0A45@tayexc14.americas.cpqcorp.net> Thread-Topic: DAD Thread-Index: AcVapLtAlXjdrinVTc26M3bmSMbMVwALNdHg From: "Bound, Jim" To: "giuseppe" , X-OriginalArrivalTime: 17 May 2005 11:38:39.0949 (UTC) FILETIME=[F88D17D0:01C55AD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: DAD 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 should be done for normal commercial links and consumer networks (houses) wired (fixed) and wireless (fixed). The execution cost is not that great in those networks for what one gets to verify EUI's are unique. But, for Mission Critical Secure Defense wireless Networks DAD can be avoided if in fact the EUI's are guaranteed to be unique on such devices, especially for MANETs. Some time soon I will post draft to MANET or Autoconfig MANET work that depicts the use of pre-DAD, boot operation of radio, and then post-DAD after boot operation of radio, and that the post-DAD operation is not needed in some cases. This would be an implementation choice, and IPv6 addrconf standard is clear that DAD is required. Thus, the risk of implementation of such a net would have to assume interoperability and uniqueness of the EUI responsibility. There is also Optimistic DAD that can be used for commercial mobile devices on wireless networks, one should review and check. But, today I am aware of no implementations that do not implement DAD or have implemented Optimistic DAD (but there are folks on this list that can correct me if Optimistic DAD has been implemented???). /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of giuseppe > Sent: Tuesday, May 17, 2005 1:48 AM > To: ipv6@ietf.org > Subject: DAD >=20 > In IPv6 stateless address autoconfiguration, how is it=20 > possible that the=20 > generated address could be duplicated? > The MAC that host appends to the link prefix is unique, isn't it? > Replies appreciated > G >=20 > --=20 > ---------------------- > ---------------------- > Giuseppe De Marco, Ph.D. >=20 > Dipartimento di Ingegneria=20 > dell'Informazione e Ingegneria Elettrica > DIIIE, University of Salerno > via ponte don Melillo 1, Fisciano, Salerno > tel: +39 089 964012 > email: gdemarco@unisa.it >=20 > Department of Information and=20 > Communication Engineering=20 > Faculty of Information Engineering=20 > Fukuoka Institute of Technology (FIT) > 3-30-1 Wajiro-Higashi, Higashi-ku, Fukuoka 811-0295=20 > Japan > email: demarco@fit.ac.jp > -------------------- >=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 Tue May 17 13:15:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5fM-0004rB-Du; Tue, 17 May 2005 13:15:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY5f6-0004pq-TN for ipv6@megatron.ietf.org; Tue, 17 May 2005 13:15:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16834 for ; Tue, 17 May 2005 13:15:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY5vt-000372-MY for ipv6@ietf.org; Tue, 17 May 2005 13:32:42 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4HGhhe13039; Tue, 17 May 2005 09:43:43 -0700 X-mProtect: <200505171643> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.55.246, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdq86Xoc; Tue, 17 May 2005 09:43:41 PDT Message-Id: <6.2.1.2.2.20050517095656.02cff978@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 17 May 2005 10:14:16 -0700 To: Thomas Narten From: Bob Hinden In-Reply-To: <200505170057.j4H0vTEE005773@cichlid.raleigh.ibm.com> References: <200505170057.j4H0vTEE005773@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ipv6@ietf.org Subject: Re: last minute review of draft-ietf-ipv6-addr-arch-v4-03.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 Thomas, At 05:57 PM 05/16/2005, Thomas Narten wrote: >Bob, > > > This raises the question I have had for a while, is when doing updates to > > existing standard what to put in the IANA section. It seems to me it > > should be what changes should be made to the IANA registries, not a > > complete copy. This is very different from the technical content of the > > document. > >Yep. And I don't have a one-size-fits all answer. I've seen some >documents just repeat the old section, but as you note that reads >funny if IANA has already done the work. > >And since this document is obsoleting RFC 3513, it seems odd to point >back to it for definitive text. > >I'm not sure the IESG has thought in a lot of detail about the >significance of obsoleting a document that contains an IANA >considerations section. > >But, having said that, when trying to find the IANA considerations >related to a name space, it can be rather interesting sometimes just >trying to track down the pointers. So, I prefer seeing at least some >pointers to other documents than nothing at all. I agree with what you are saying. The problem here is that even RFC3513 isn't consistent with what is on the IANA page (http://www.iana.org/assignments/ipv6-address-space). It was, of course, changed the RFC3879, RFC-carpenter-obsolete-1888-01.txt, and RFC-huston-ip6-iana-registry-05.txt. Some of the history for each entry can be deduced from the references on the IANA page, but I agree it is not the complete history. It would be nice if the IANA kept a publicly accessible log of each change. That might helpful in the future. >My wording was an attempt to provide at least the start of a >reference, while still making it clear that this document isn't >changing any of the rules that are already in place. I understand. > > Instead of what you suggested, I think something like the following would > > be better: > > > No other IANA IPv6 address registries need to be changed based on > > this document. > >For me, having a reference to other documents is really the purpose of >adding something to this section. The above doesn't really add much >beyond complete silence. It does at least say nothing else was changed :-) > > A few reasons for this include the references to 3513 and 3307 doesn't > > capture the complete history of the current IANA registries and this > > document will obsolete 3513 and this might make the note confusing. > >Another possibility is to include some (but perhaps not the entire >table) from RFC 3513, but point out that the new text is being >included for completeness and doesn't establish any new policy. That >might be a better the referring to an obsoleted document. As noted above, the format was changed in RFC-huston-ip6-iana-registry-05.txt so that might well cause more confusion. We wouldn't want the IANA to change it back to the old format. :-( >What I was trying to achieve was a balance between repeating all the >history (which is sometimes a bit convoluted) with at least a pointer >on where to get started for the details. But maybe we shouldn't even >go here... :-( I agree, there isn't any simple solution. I am starting to think it best to not say anything else about the history here short of trying to capture the whole history. What do you think? Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 17 15:41:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wo-0006i2-FH; Tue, 17 May 2005 15:41:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wm-0006g9-NL; Tue, 17 May 2005 15:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01281; Tue, 17 May 2005 15:41:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8Da-0002be-SH; Tue, 17 May 2005 15:59:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 15:41:36 -0400 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 j4HJexni015571; Tue, 17 May 2005 15:41:27 -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, 17 May 2005 15:41:26 -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, 17 May 2005 15:41:25 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B370E@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVahGdhDLV9JhwsRneDDXLPFEI82gAk6wCg From: "Bernie Volz \(volz\)" To: "timothy enos" , "Pekka Savola" X-OriginalArrivalTime: 17 May 2005 19:41:26.0296 (UTC) FILETIME=[69D6E180:01C55B18] X-Spam-Score: 1.1 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, JINMEI Tatuya / ???? , IPv6 WG , "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Tim: I'm not sure what you mean by your question ... SLAC (stateless auto-configuration) is independent of stateful. There may be some prefixes on a link that are stateful (0 or more) and others that are stateless (0 or more - excluding the link-local which is always stateless). So, SLAC is independent of stateful (DHCPv6). - Bernie > -----Original Message----- > From: timothy enos [mailto:timbeck04@verizon.net]=20 > Sent: Monday, May 16, 2005 10:00 PM > To: Bernie Volz (volz); 'Pekka Savola' > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI=20 > Tatuya / ????' > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Bernie, > =09 > Your points are well taken, and I agree. Making these flags 'hints' > makes sense. Also, it seems that if a client does not know what to do > (forgive the anthropomorphism) in response to having received=20 > an RA with > the M (and O) bit(s) set (because it is not a DHCPv6 client), it would > just ignore it/them.=20 >=20 > Also wondering if there are any RFC 3315-capable clients that, after > failing to get config info from a DHCPv6 server 'x' times,=20 > would revert > to SLAC? >=20 > Tim Enos > 1Sam16:7 >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of > Bernie Volz (volz) > Sent: Monday, May 16, 2005 5:20 PM > To: Pekka Savola > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI=20 > Tatuya / ???? > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Hey, if they don't know what they're doing then set the bits=20 > and be done > with it. If there's no DHCP server, the clients will try to get > configuration information and fail and continuously try in the > background. That's the safest fallback and the recommended default, > IMHO. >=20 > If they do set them wrong, it won't take long for users to complain. > Just as they do now if the DHCP server or routing infrastructure is > down. >=20 > Trying to design for stupidity only produces the same. >=20 > - Bernie=20 >=20 > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > > Sent: Monday, May 16, 2005 5:09 PM > > To: Bernie Volz (volz) > > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph=20 > > Droms (rdroms) > > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > >=20 > > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > > BTW, if you want to look at this from the router administrator's > > > perspective: > > > > > > Configure the router to send the M flag set in routing=20 > > advertisements > > > for a Link IF: > > > 1. A stateful DHCP server is deployed for that link=20 > (either on it or > > > reachable via a relay agent) AND > >=20 > > IMHO, you're making a significant leap of faith in assuming that=20 > > whoever configures the router's M-flag advertisements has=20 > sufficient=20 > > clue to grasp the different semantics that arise with: > >=20 > > - M-flag and/or O-flag > > - stateless and stateful clients > > - stateless and stateful servers > > - stateless and stateful relay agents > >=20 > > Hence, if we want to build a robust system, we need to=20 > design it with=20 > > care. > >=20 > >=20 > >=20 > > --=20 > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >=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 Tue May 17 16:33:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8l9-0002Da-Lj; Tue, 17 May 2005 16:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY8l6-0002Ab-Cn; Tue, 17 May 2005 16:33:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15576; Tue, 17 May 2005 16:33:41 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8yl-0008RT-MS; Tue, 17 May 2005 16:47:52 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 May 2005 16:30:20 -0400 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 j4HKToeM023740; Tue, 17 May 2005 16:30:17 -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, 17 May 2005 16:30:05 -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, 17 May 2005 16:30:04 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B373A@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVahGdhDLV9JhwsRneDDXLPFEI82gAk6wCgAAD0MnA= From: "Bernie Volz \(volz\)" To: "timothy enos" , "Pekka Savola" X-OriginalArrivalTime: 17 May 2005 20:30:05.0206 (UTC) FILETIME=[35A53360:01C55B1F] X-Spam-Score: 1.1 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Pekka suggested you might have been referring to stateless DHCPv6 - ie, when does a DHCPv6 client doing stateful DHCPv6 switch to doing stateless DHCPv6? I don't believe we had any specific text in this regard in 3315 or 3736 and is thus likely an issue for 3315-bis. I assume you're asking this in the case where both the M and O flags are set? And, I can see three techniques: 1. If the client supports stateful always use stateful and never switch to stateless. 2. Try stateful for a few (perhaps only 1 Solicit / Advertise) cycles and if there are no responses or only "error" responses, continue stateful but also initiate stateless. The start of stateless could be controlled by the O flag. 2. Always start both. Personally, I like the first best as I would expect that if the M flag is set and no DHCPv6 server responds, sending Information-Request messages will also not yield anything useful. But, this does not work if the default were to always set the M and O bits in RAs but only have a stateless server. That's why I think we've made mistakes in the DHCPv6 specifications: 1. For 3315, we should have had a status return code for an Advertise that says "no stateful service available." Note that this is different than the NoAddrsAvail status we presently have.=20 2. For 3736, we should have required Solicit and Advertise to be supported by the stateless DHCPv6 server such that it could return just the "no stateful service available" status for any Solicits it receives. That way, if the only servers to respond to Solicits all return "no stateful service available", the client knows what to do. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bernie Volz (volz) > Sent: Tuesday, May 17, 2005 3:41 PM > To: timothy enos; Pekka Savola > Cc: dhcwg@ietf.org; JINMEI Tatuya / ????; IPv6 WG; Ralph=20 > Droms (rdroms) > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 > Tim: >=20 > I'm not sure what you mean by your question ... SLAC (stateless > auto-configuration) is independent of stateful. There may be some > prefixes on a link that are stateful (0 or more) and others that are > stateless (0 or more - excluding the link-local which is always > stateless). >=20 > So, SLAC is independent of stateful (DHCPv6). >=20 > - Bernie >=20 > > -----Original Message----- > > From: timothy enos [mailto:timbeck04@verizon.net]=20 > > Sent: Monday, May 16, 2005 10:00 PM > > To: Bernie Volz (volz); 'Pekka Savola' > > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI=20 > > Tatuya / ????' > > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > >=20 > > Bernie, > > =09 > > Your points are well taken, and I agree. Making these flags 'hints' > > makes sense. Also, it seems that if a client does not know=20 > what to do > > (forgive the anthropomorphism) in response to having received=20 > > an RA with > > the M (and O) bit(s) set (because it is not a DHCPv6=20 > client), it would > > just ignore it/them.=20 > >=20 > > Also wondering if there are any RFC 3315-capable clients that, after > > failing to get config info from a DHCPv6 server 'x' times,=20 > > would revert > > to SLAC? > >=20 > > Tim Enos > > 1Sam16:7 > >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > > Behalf Of > > Bernie Volz (volz) > > Sent: Monday, May 16, 2005 5:20 PM > > To: Pekka Savola > > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI=20 > > Tatuya / ???? > > Subject: RE: [dhcwg] Re: IPv6 WG Last > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > >=20 > > Hey, if they don't know what they're doing then set the bits=20 > > and be done > > with it. If there's no DHCP server, the clients will try to get > > configuration information and fail and continuously try in the > > background. That's the safest fallback and the recommended default, > > IMHO. > >=20 > > If they do set them wrong, it won't take long for users to complain. > > Just as they do now if the DHCP server or routing infrastructure is > > down. > >=20 > > Trying to design for stupidity only produces the same. > >=20 > > - Bernie=20 > >=20 > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > > > Sent: Monday, May 16, 2005 5:09 PM > > > To: Bernie Volz (volz) > > > Cc: JINMEI Tatuya / ????; dhcwg@ietf.org; IPv6 WG; Ralph=20 > > > Droms (rdroms) > > > Subject: RE: [dhcwg] Re: IPv6 WG Last=20 > > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > >=20 > > > On Mon, 16 May 2005, Bernie Volz (volz) wrote: > > > > BTW, if you want to look at this from the router administrator's > > > > perspective: > > > > > > > > Configure the router to send the M flag set in routing=20 > > > advertisements > > > > for a Link IF: > > > > 1. A stateful DHCP server is deployed for that link=20 > > (either on it or > > > > reachable via a relay agent) AND > > >=20 > > > IMHO, you're making a significant leap of faith in assuming that=20 > > > whoever configures the router's M-flag advertisements has=20 > > sufficient=20 > > > clue to grasp the different semantics that arise with: > > >=20 > > > - M-flag and/or O-flag > > > - stateless and stateful clients > > > - stateless and stateful servers > > > - stateless and stateful relay agents > > >=20 > > > Hence, if we want to build a robust system, we need to=20 > > design it with=20 > > > care. > > >=20 > > >=20 > > >=20 > > > --=20 > > > Pekka Savola "You each name yourselves=20 > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A=20 > Clash of Kings > > >=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 > -------------------------------------------------------------------- >=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 May 17 18:17:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYANN-0001ww-24; Tue, 17 May 2005 18:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYANK-0001wm-Ix for ipv6@megatron.ietf.org; Tue, 17 May 2005 18:17:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26696 for ; Tue, 17 May 2005 18:17:15 -0400 (EDT) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYAe8-0006iW-LM for ipv6@ietf.org; Tue, 17 May 2005 18:34:42 -0400 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 965037000A8; Wed, 18 May 2005 08:17:11 +1000 (EST) Date: Wed, 18 May 2005 08:17:09 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20050517221708.GA2640@zoic.org> Mail-Followup-To: ipv6@ietf.org References: <936A4045C332714F975800409DE092403F0A45@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE092403F0A45@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Re: DAD 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 2005-05-17, Bound, Jim wrote: > > There is also Optimistic DAD that can be used for commercial mobile > devices on wireless networks, one should review and check. But, today I > am aware of no implementations that do not implement DAD or have > implemented Optimistic DAD (but there are folks on this list that can > correct me if Optimistic DAD has been implemented???). Optimistic DAD is in the Standards Track queue now. We implemented it for Linux as part of the development process, and I'll make the patch available again soon ... I'm working on other things until the IESG/etc comments come back, then I'll update the patch and release. Some vendors have expressed their interest in implementing once it is nailed down in an RFC. Linux, at least, can be set up to not run DAD very simply by setting the DAD retransmits parameter to 0. Whether this is a good idea is another matter. There's some discussion of the original poster's question in the OptiDAD draft: see draft-ietf-ipv6-optimistic-dad-05.txt cheers, -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 17 19:52:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYBrK-0004rJ-KI; Tue, 17 May 2005 19:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYBrI-0004r4-C9; Tue, 17 May 2005 19:52:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04330; Tue, 17 May 2005 19:52:16 -0400 (EDT) Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYC87-0003Kc-Pv; Tue, 17 May 2005 20:09:45 -0400 Received: from S018431 ([141.154.125.12]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGN0051ERN2QBX5@vms044.mailsrvcs.net>; Tue, 17 May 2005 18:52:16 -0500 (CDT) Date: Tue, 17 May 2005 19:52:12 -0400 From: "timothy enos" In-reply-to: <8E296595B6471A4689555D5D725EBB212B370E@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz \(volz\)'" , "'Pekka Savola'" Message-id: <001a01c55b3b$72ac9c00$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: 2.1 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'JINMEI Tatuya / ????' , 'IPv6 WG' , "'Ralph Droms \(rdroms\)'" Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Bernie, I'm well aware that stateful (DHCPv6, RFC 3315) and SLAC (RFC 2462) are independent of one another; not sure what in my question was unclear. While not required, I do appreciate the explanation. However my question is answered in RFC 3315, page 33 (section 17.1.2) quoted below: "A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link." My question was whether or not there are any existing implementations wherein a DHCPv6 client, after its MRC (being a positive integer) is reached, will then (as a backup or alternate method) seek to use SLAC. If so, they would clearly be in violation of the MUST as quoted above. The original question in this thread seemed to be about the M and O flags. I'd reaffirm that I agree with your contention on 16May05, 10:04am, quoted below: "In IPv6, the M and O flag should serve as hints. Period. A host is perfectly free to do what it wants (or what it has been configured to do)." Best regards, Tim 1Sam16:7 -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Tuesday, May 17, 2005 3:41 PM To: timothy enos; Pekka Savola Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI Tatuya / ???? Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Tim: I'm not sure what you mean by your question ... SLAC (stateless auto-configuration) is independent of stateful. There may be some prefixes on a link that are stateful (0 or more) and others that are stateless (0 or more - excluding the link-local which is always stateless). So, SLAC is independent of stateful (DHCPv6). - Bernie > -----Original Message----- > From: timothy enos [mailto:timbeck04@verizon.net] > Sent: Monday, May 16, 2005 10:00 PM > To: Bernie Volz (volz); 'Pekka Savola' > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI > Tatuya / ????' > Subject: RE: [dhcwg] Re: IPv6 WG Last > Call:draft-ietf-ipv6-ra-mo-flags-01.txt > > Bernie, > > Your points are well taken, and I agree. Making these flags 'hints' > makes sense. Also, it seems that if a client does not know what to do > (forgive the anthropomorphism) in response to having received > an RA with > the M (and O) bit(s) set (because it is not a DHCPv6 client), it would > just ignore it/them. > > Also wondering if there are any RFC 3315-capable clients that, after > failing to get config info from a DHCPv6 server 'x' times, > would revert > to SLAC? > > 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 Tue May 17 20:05:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYC3c-0001Cc-V2; Tue, 17 May 2005 20:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYC3a-0001Bo-Bf for ipv6@megatron.ietf.org; Tue, 17 May 2005 20:05:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05697 for ; Tue, 17 May 2005 20:05:00 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYCKQ-00047w-SO for ipv6@ietf.org; Tue, 17 May 2005 20:22:27 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 5AFF620000EE; Tue, 17 May 2005 20:04:51 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 May 2005 20:04:51 -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, 17 May 2005 20:04:49 -0400 Message-ID: <936A4045C332714F975800409DE092403F0DA7@tayexc14.americas.cpqcorp.net> Thread-Topic: DAD Thread-Index: AcVbLnpjAtIZXcuZQMmx9N40wXH1gwADrdbw From: "Bound, Jim" To: "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 18 May 2005 00:04:51.0274 (UTC) FILETIME=[365722A0:01C55B3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: DAD 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 thanks Nick. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Nick 'Sharkey' Moore > Sent: Tuesday, May 17, 2005 6:17 PM > To: ipv6@ietf.org > Subject: Re: DAD >=20 > On 2005-05-17, Bound, Jim wrote: > > > > There is also Optimistic DAD that can be used for commercial mobile > > devices on wireless networks, one should review and check. =20 > But, today I > > am aware of no implementations that do not implement DAD or have > > implemented Optimistic DAD (but there are folks on this=20 > list that can > > correct me if Optimistic DAD has been implemented???). >=20 > Optimistic DAD is in the Standards Track queue now. > We implemented it for Linux as part of the development process, and > I'll make the patch available again soon ... I'm working on other > things until the IESG/etc comments come back, then I'll update the > patch and release. Some vendors have expressed their interest in > implementing once it is nailed down in an RFC. >=20 > Linux, at least, can be set up to not run DAD very simply by setting > the DAD retransmits parameter to 0. Whether this is a good idea is > another matter. >=20 > There's some discussion of the original poster's question in the > OptiDAD draft: see draft-ietf-ipv6-optimistic-dad-05.txt >=20 > cheers, >=20 > -----Nick >=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 May 18 04:13:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJde-0002XA-13; Wed, 18 May 2005 04:10:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJdW-0002Vq-JI; Wed, 18 May 2005 04:10:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15917; Wed, 18 May 2005 04:10:36 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYJuM-0003ud-6U; Wed, 18 May 2005 04:28:07 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2912D15210; Wed, 18 May 2005 17:12:33 +0900 (JST) Date: Wed, 18 May 2005 17:11:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.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: 67c1ea29f88502ef6a32ccec927970f0 Cc: dhcwg@ietf.org, IPv6 WG , Pekka Savola , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Mon, 16 May 2005 09:56:26 -0400, >>>>> "Bernie Volz (volz)" said: > I haven't followed this thread carefully, but are you trying to suggest > that if the M flag is set but O is not, that a client would IGNORE the > other configuration parameters received from a DHCP server in a > Solicit/Advertise/Request/Reply sequence? Nope. Not at all. Perhaps I was just not very clear, but I basically agree with your understanding (and opinions) below (and so do all of us, I believe). In particular, - I didn't intend to *force* a host (client) to take a particular action. - I agree that the M or O flag is just a "hint" about available configuration methods. And, in fact, in draft-ietf-ipv6-ra-mo-flags-01.txt we do not use any "MUST" or "MUST NOT" with one exception which is actually a citation from another document. Also, we introduced separate "policy variables" for hosts so that they can act based on their own decision, regardless of the RA flags. What I was trying to address is to avoid an undesirable situation for hosts when not everything is perfectly working. For example, consider the case where we provide both address allocation via DHCPv6 and also the stateless service (the RFC3736 subset of DHCPV6) in a network. As you mentioned in a separate message, we can think of a scenario in which it makes sense for a host to use the information provided via the RFC3736 subset but not use address allocation via DHCPv6. In this case, both the M and O flags in RAs would be set to ON. Now, suppose that there is a reachability trouble from a host to all available DHCPv6 servers that provide the address allocation service, but some of the RFC3736 DHCPv6 servers can be reached (I think this can happen because the latter can be more lightweight. For example, some or all of routers in the host subnets would probably be able to act as the RFC3736 DHCPv6 server without offering any addresses to be allocated to the client). Or worse, there may be a configuration error that the router administrator sets the M flag ON while there is actually no address allocation service via DHCPv6 available. This is a special case of the above "reachable trouble". In such cases, if the host can still do meaningful operation (this can happen, as you pointed out in a separate message) even without being allocated global addresses via DHCPv6, it would want to get other configuration information via the available RFC3736 service. What I want to clarify in the draft-ietf-ipv6-ra-mo-flags-01.txt document is to provide operational guideline for hosts in such cases. Specifically, I proposed to explicitly allow the host to perform the address allocation exchanges and the RFC3736 exchange concurrently in that document. Someone may want to point out that such a behavior is not prohibited in RFC3315 and that we don't have to emphasize that in a separate document. But at least I was previously confused about whether this is a valid behavior, so I believe it makes sense to mention that explicitly. And finally, I admit the above examples can be an issue only when something unexpected happens (e.g., when the administrator misconfigures the router, or under a reachability problem). I personally still think it makes sense to provide a guideline so that the host can get as much configuration information as possible even under a small administrative error (again, I'm not intending to *force* a particular action for such cases). But if many others think this is too minor to mention the ra-mo-flags document explicitly, I'll follow that decision. Am I now clear enough? (I believe this response also covers the rest of the messages in this thread or some of the other messages talk about different things I intended to discuss, so I won't explicitly reply to the other messages for now. If I still miss something crucial in the other messages, please point it out.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp > That seems very bad to me. And > a waste of resources to have to do two sets of transactions > (Solicit/Advertise/Request/Reply for addresses and > Information-Request/Reply for other configuration). > I really don't understand why this issue has been so difficult to > resolve. > In IPv4, DHCP is often the default unless you explicitly configure an > interface or turn DHCP off. We don't have ANY network wide configuration > for this. And it works very well indeed. > In IPv6, the M and O flag should serve as hints. Period. A host is > perfectly free to do what it wants (or what it has been configured to > do). > The M flag, if set, means a host SHOULD do full-RFC 3315. This means > they should attempt to Solicit, but can also fall back to > Information-Request if needed. This means both addresses and other > configuration are configured, if available. > The O flag, if set, means a host SHOULD do RFC 3376 (partial RFC 3315). > If both flags are set, hosts that can do full RFC 3315 do it (and ignore > the O flag). Those that can only do RFC 3376, do that. > If no flag it set, hosts may still do RFC 3315 and/or 3376 if so > configured (whether by default or otherwise). There should be no > prohibition against doing that. The document need not say this - it is > implied because we MUST NOT use MUST or MUST NOT. Just SHOULD or SHOULD > NOT when taking about 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 May 18 12:31:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRRm-0002tw-Cb; Wed, 18 May 2005 12:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYRRk-0002to-O2; Wed, 18 May 2005 12:31:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09520; Wed, 18 May 2005 12:30:55 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYRig-000091-He; Wed, 18 May 2005 12:48:32 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4IGUjMk031569; Wed, 18 May 2005 12:30:45 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4IGUjPE154700; Wed, 18 May 2005 12:30:45 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4IGUdUB006546; Wed, 18 May 2005 12:30:39 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-48-34-201.mts.ibm.com [9.48.34.201]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4IGUd0e006523; Wed, 18 May 2005 12:30:39 -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 j4IGTKmt005705; Wed, 18 May 2005 12:29:20 -0400 Message-Id: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> To: "Bernie Volz \(volz\)" In-Reply-To: Message from "Bernie Volz \(volz\)" of "Mon, 16 May 2005 09:56:26 EDT." <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> Date: Wed, 18 May 2005 12:29:20 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , IPv6 WG , Pekka Savola , JINMEI Tatuya / ???? Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Let me just start off by saying I pretty much agree completely with what Bernie just said. I've also reviewed this document, and I am really wondering what this document is trying to achieve. It seems to me that its added a lot of text (that IMO is not really needed). In particular, I don't think either Section 6 or 7 are necessary or appropriate. There are really only two behaviors a client should be doing. If a client doesn't implement DHC, well, then it obviously shouldn't/can't invoke DHC. End of story. If it does implement DHC, well, it should use it. Moreover, it shold never really be a "client" choice whether to invoke use DHC or not. If the sys admin has stuff available via DHC, the client should (in the SHOULD sense) be getting it and using it. Why on earth would we want to disable that via a configuration knob? Indeed, when I look at Section 2, "Background", I find that the wording that it quotes from RFC 2461 really does say pretty much what should be said. That is, these bits are "hints" that the local sys admin has a DHC server that is giving out addresses and/or other configuration information. Seems to me, if the local access network is giving out config information, clients SHOULD try and get it, because if they don't, they will presumably operate at some sort of reduced level of functionality -- after all, if a sys admin set up a DHC server, there must be a reason for this (e.g., to provide DNS recursive name server service, addresses not available via stateless addrconf, etc.). So, these bits should just provide clients with a stronger indication that they should be using DHC to get the information that is available. If the original 2461 text is really deemed insufficient, how about something like: o M : 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6], including addresses that were not configured via stateless address autoconfiguration. Clients SHOULD use DHC to obtain addresses (and associated configuration information) as described in [ADDRCONF]. Note that when the M bit is set, the setting of the O bit is irrelevant, since the DHC server will return "other" configuration information together with addresses. o O : 1-bit "Other configuration" flag. When set, it indicates that [DHCPv6lite] is available for autoconfiguration of other (non-address) information. Examples of such information are DNS-related information or information on other servers within the network. When set, - If the M bit is also set, clients SHOULD use DHC to obtain addresses (and associated configuration information) as described above. - If the M bit is not set, clients SHOULD use DHC as described in RFC 3736. Is more than something like the above _really_ needed? If so, why? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 18 17:46:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYWNV-0004v3-KZ; Wed, 18 May 2005 17:46:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYWNT-0004tN-H7 for ipv6@megatron.ietf.org; Wed, 18 May 2005 17:46:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25106 for ; Wed, 18 May 2005 17:46:52 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYWeS-0001zX-6y for ipv6@ietf.org; Wed, 18 May 2005 18:04:28 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4ILFVW05968 for ; Wed, 18 May 2005 14:15:31 -0700 X-mProtect: <200505182115> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdMtpCzf; Wed, 18 May 2005 14:15:29 PDT Message-Id: <6.2.1.2.2.20050518143251.02f60f90@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 18 May 2005 14:46:27 -0700 To: ipv6@ietf.org From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: Proposed changes to IPv6 Address Architecture draft 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, The proposed changes in Section 2.7 on Multicast Addresses and Section 4.0 IANA Considerations can be found below. The changes are based on the issues raised by Thomas Narten and the IANA. I believe this will resolve the issues. The complete document can be found at: http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-04.txt along with a diff from the previous version. http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-04.html Please review and let me know if you find any problems. I plan to submit this in a few days. Thanks, Bob ----------------------------------- 2.7 Multicast Addresses An IPv6 multicast address is an identifier for a group of interfaces (typically on different nodes). An interface may belong to any number of multicast groups. Multicast addresses have the following format: | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ binary 11111111 at the start of the address identifies the address as being a multicast address. +-+-+-+-+ flgs is a set of 4 flags: |0|R|P|T| +-+-+-+-+ The high-order flag is reserved, and must be initialized to 0. T = 0 indicates a permanently-assigned ("well-known") multicast address, assigned by the Internet Assigned Number Authority (IANA). T = 1 indicates a non-permanently-assigned ("transient" or "dynamically" assigned) multicast address. The P flag's definition and usage can be found in [RFC3306]. The R flag's definition and usage can be found in [RFC3956]. scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are: 0 reserved 1 interface-local scope 2 link-local scope 3 reserved 4 admin-local scope 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope F reserved interface-local scope spans only a single interface on a node, and is useful only for loopback transmission of multicast. link-local multicast scope spans the same topological region as the corresponding unicast scope. admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. site-local scope is intended to span a single site. organization-local scope is intended to span multiple sites belonging to a single organization. scopes labeled "(unassigned)" are available for administrators to define additional multicast regions. group ID identifies the multicast group, either permanent or transient, within the given scope. Additional definitions of the multicast group ID field structure is defined in [RFC3306]. ------------------------------------- 4. IANA Considerations The "IPv4-compatible IPv6 address" is deprecated by this document. The IANA should continue to list the address block containing these addresses at http://www.iana.org/assignments/ipv6-address-space as "Reserved by IETF" and not reassign it for any other purpose. For example: 0000::/8 Reserved by IETF [RFC3513] [1] The IANA is requested to add the following note and link it to this address block. [5] 0000::/96 was previously defined as the "IPv4-compatible IPv6 address" prefix. This definition has been deprecated by [RFC-ietf-ipv6-addr-arch-v4-04.txt]. The IANA is requested to update the references for the IPv6 Address Architecture in the IANA registries to this RFC when it is published. ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 18 19:37:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYY6c-00052p-Rw; Wed, 18 May 2005 19:37:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYY6a-00052h-87 for ipv6@megatron.ietf.org; Wed, 18 May 2005 19:37:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06132 for ; Wed, 18 May 2005 19:37:32 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYYNb-0005kg-CD for ipv6@ietf.org; Wed, 18 May 2005 19:55:13 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:65cf:41f1:9582:c383]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C989015210; Thu, 19 May 2005 08:39:43 +0900 (JST) Date: Thu, 19 May 2005 08:38:24 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman In-Reply-To: <0fb3601844cbf3e3999b0bf94bda49a2@innovationslab.net> References: <200505061944.PAA29056@ietf.org> <0fb3601844cbf3e3999b0bf94bda49a2@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: 36c793b20164cfe75332aa66ddb21196 Cc: IPv6 WG Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-11.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 Mon, 9 May 2005 10:56:35 -0400, >>>>> Brian Haberman said: > A refreshed version of the ICMP Name Lookups draft is available. > I would especially like WG members who have implementations to > review the draft and point out discrepancies between the spec and > their code (e.g. unimplemented features). Thanks for your effort of revising the document. I've reviewed the latest draft, and have some comments. (I must confess in advance that I don't fully remember the past discussions on this document, and that I may be repeating points already discussed before.) Regarding discrepancy with our (KAME/BSD) implementation, whereas I've not done "line-by-line" checks between the spec and the implementation, it seems the implementation supports all the features described in the latest draft type/code/Qtype-wise. However, - our implementation currently does NOT delay the response to an anycasted or multicasted query. - it does NOT support the proxy responder service. - it still supports the "Supported Qtypes" Qtype which is now marked as "unused" (as far as I know this is just because we've not fully followed recent changes of the spec). Other general comments follow: 1. In section 2, this document is too specific about particular implementations: [...] An example of a IPv6 debugging tool using IPv6 Node Information Queries is the ping6 program in the KAME, USAGI, and other IPv6 implementations . I'm afraid this is not very appropriate for a general specification document. Instead, we might say: [...] An example of an IPv6 debugging tool using IPv6 Node Information Queries is the ping6 program in some platforms. 2. it seems to me that the notion of "proxy" is suddenly introduced in Section 5. I think it should be clearly defined beforehand, e.g., in Section 3. 3. In Section 3, the draft reads: The Query concerns a "Subject Address" (which may differ from the Queried Address) or a "Subject Name". We may also want to note that the Subject Address is not even an IPv6 address (i.e., it can be an IPv4 address). 4. I'm afraid the reference to the MD5 spec (RFC1321) in Section 5 should be a normative reference in this context. (If icmp-name-lookups is expected to be published as a PS, this may cause a problem since RFC1321 is informational.) 5. I don't see why we need the TTL field for Node Name, Node Addresses, and IPv4 Addresses if it MUST be always 0. Perhaps this is just for backward compatibility to existing implementations, though...(if so, I believe we should explicitly note that, since otherwise future readers will have the same question) 6. In section 5, the draft reads: [...] If the Queried Address was anycast or multicast, the source address for the Reply SHOULD be one belonging to the interface on which the Query was received. I don't see the strong reason in this case for choosing the source address on the receiving interface. If we need to give guidance about the source address in these cases, I think we can (or even should) just refer to RFC3484. 7. Should we still need the "S" and "C" flags for the Node Addresses Query even though site-local unicast addresses and IPv4-compatible IPv6 addresses are now deprecated? 8. RFC2535 (DNSSEC) was updated by RFC4033-4035. We may want to update the reference as well. And here are some editorial comments: (throughout the document) "a NI" should be "an NI"? (depending on how we pronounce the acronym, of course). (section 2) [...] An example of a IPv6 debugging tool using IPv6 Node => An example of an IPv6 debugging tool... (section 5) Providing the infrastructure to authenticate NI Queries and Replies may be quote difficult outside of a well-defined community. => ... may be quite difficult(?) (section 6.3) [...] The Reply Data is a sequence of 128-bit IPv6 addresses, each address preceded by separate a 32-bit TTL value, with => ... by a separate 32-bit TTL value (?) (section 7) The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0: 0:2::/96 for use in Node Information Queries as defined in section Section 5. => ... in Section 5. (i.e., remove the redundant "section") 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 Wed May 18 20:16:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYYh2-0008Aw-UO; Wed, 18 May 2005 20:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYYh0-0008An-Km for ipv6@megatron.ietf.org; Wed, 18 May 2005 20:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08979 for ; Wed, 18 May 2005 20:15:12 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYYy3-0006kY-Pg for ipv6@ietf.org; Wed, 18 May 2005 20:32:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4INhoQ27377; Wed, 18 May 2005 16:43:50 -0700 X-mProtect: <200505182343> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpddQloWi; Wed, 18 May 2005 16:43:49 PDT Message-Id: <6.2.1.2.2.20050518170330.02c8bd40@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 18 May 2005 17:14:46 -0700 To: "ext JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= " From: Bob Hinden In-Reply-To: References: <200505061944.PAA29056@ietf.org> <0fb3601844cbf3e3999b0bf94bda49a2@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Brian Haberman , IPv6 WG Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-11.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 Jinmei, >Thanks for your effort of revising the document. I've reviewed the >latest draft, and have some comments. (I must confess in advance that >I don't fully remember the past discussions on this document, and that >I may be repeating points already discussed before.) I have a few thoughts on your comments based on my memory of the history :-) I was partially responsible for the previous version. Bob >Regarding discrepancy with our (KAME/BSD) implementation, whereas I've >not done "line-by-line" checks between the spec and the implementation, >it seems the implementation supports all the features described in the >latest draft type/code/Qtype-wise. > >However, > - our implementation currently does NOT delay the response to an > anycasted or multicasted query. The question here is the delay useful. To me this would seem useful for multicast queries, but I don't see the need for ones for anycast. > - it does NOT support the proxy responder service. > - it still supports the "Supported Qtypes" Qtype which is now marked > as "unused" (as far as I know this is just because we've not fully > followed recent changes of the spec). > >Other general comments follow: > >1. In section 2, this document is too specific about particular > implementations: > > [...] An example of a IPv6 debugging tool using IPv6 Node > Information Queries is the ping6 program in the KAME, USAGI, and > other IPv6 implementations . > > I'm afraid this is not very appropriate for a general specification > document. Instead, we might say: This was there purposely. At one point there was a lot of push back on moving this forward and it was useful to be very specific about where this was implemented and being used. > [...] An example of an IPv6 debugging tool using IPv6 Node > Information Queries is the ping6 program in some platforms. > >2. it seems to me that the notion of "proxy" is suddenly introduced in > Section 5. I think it should be clearly defined beforehand, e.g., > in Section 3. > >3. In Section 3, the draft reads: > > The Query concerns a "Subject Address" (which may > differ from the Queried Address) or a "Subject Name". > > We may also want to note that the Subject Address is not even an > IPv6 address (i.e., it can be an IPv4 address). > >4. I'm afraid the reference to the MD5 spec (RFC1321) in Section 5 > should be a normative reference in this context. (If > icmp-name-lookups is expected to be published as a PS, this may > cause a problem since RFC1321 is informational.) I don't think that would be a problem. >5. I don't see why we need the TTL field for Node Name, Node > Addresses, and IPv4 Addresses if it MUST be always 0. Perhaps this > is just for backward compatibility to existing implementations, > though...(if so, I believe we should explicitly note that, since > otherwise future readers will have the same question) It is left for backward compatibility. I agree it would be good to explain this. >6. In section 5, the draft reads: > > [...] If the > Queried Address was anycast or multicast, the source address for the > Reply SHOULD be one belonging to the interface on which the Query was > received. > > I don't see the strong reason in this case for choosing the source > address on the receiving interface. If we need to give guidance > about the source address in these cases, I think we can (or even > should) just refer to RFC3484. > >7. Should we still need the "S" and "C" flags for the Node Addresses > Query even though site-local unicast addresses and IPv4-compatible > IPv6 addresses are now deprecated? I think it is useful to leave them for backwards comparability. We might want to add some text explaining this. >8. RFC2535 (DNSSEC) was updated by RFC4033-4035. We may want to > update the reference as well. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 19 03:42:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYfgC-0000vB-6I; Thu, 19 May 2005 03:42:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYfg9-0000rG-4L for ipv6@megatron.ietf.org; Thu, 19 May 2005 03:42:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29994 for ; Thu, 19 May 2005 03:42:47 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYfxD-0000Cv-2A for ipv6@ietf.org; Thu, 19 May 2005 04:00:30 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4J7gJX02442; Thu, 19 May 2005 10:42:19 +0300 Date: Thu, 19 May 2005 10:42:19 +0300 (EEST) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050518143251.02f60f90@mailhost.iprg.nokia.com> Message-ID: References: <6.2.1.2.2.20050518143251.02f60f90@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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org Subject: Re: Proposed changes to IPv6 Address Architecture draft 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, 18 May 2005, Bob Hinden wrote: > The proposed changes in Section 2.7 on Multicast Addresses and Section 4.0 > IANA Considerations can be found below. The changes are based on the issues > raised by Thomas Narten and the IANA. I believe this will resolve the > issues. You might want to add a note in the changelog about the multicast address update, but even without doing so the changes looked reasonable. -- 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 Thu May 19 12:17:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYniV-0000ah-0X; Thu, 19 May 2005 12:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYniT-0000ac-HN for ipv6@megatron.ietf.org; Thu, 19 May 2005 12:17:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21413 for ; Thu, 19 May 2005 12:17:42 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYnze-0006o1-2C for ipv6@ietf.org; Thu, 19 May 2005 12:35:31 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4JFkBf19310; Thu, 19 May 2005 08:46:11 -0700 X-mProtect: <200505191546> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdVuSzEF; Thu, 19 May 2005 08:46:09 PDT Message-Id: <6.2.1.2.2.20050519091314.02d88168@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 19 May 2005 09:17:08 -0700 To: Pekka Savola From: Bob Hinden In-Reply-To: References: <6.2.1.2.2.20050518143251.02f60f90@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: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org Subject: Re: Proposed changes to IPv6 Address Architecture draft 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 Pekka, At 12:42 AM 05/19/2005, Pekka Savola wrote: >On Wed, 18 May 2005, Bob Hinden wrote: >>The proposed changes in Section 2.7 on Multicast Addresses and Section >>4.0 IANA Considerations can be found below. The changes are based on the >>issues raised by Thomas Narten and the IANA. I believe this will resolve >>the issues. > >You might want to add a note in the changelog about the multicast address >update, but even without doing so the changes looked reasonable. Good suggestion. I will add something like: o Added the "R" and "P" flags to Section 2.7 on Multicast addresses, and pointers to the documents that define them. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 19 15:05:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqKe-0006tH-RM; Thu, 19 May 2005 15:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqKc-0006t7-LT for ipv6@megatron.ietf.org; Thu, 19 May 2005 15:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08211 for ; Thu, 19 May 2005 15:05:16 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYqbn-0003KX-2h for ipv6@ietf.org; Thu, 19 May 2005 15:23:06 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:65cf:41f1:9582:c383]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3E5F81521E; Fri, 20 May 2005 04:07:21 +0900 (JST) Date: Fri, 20 May 2005 04:05:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050518170330.02c8bd40@mailhost.iprg.nokia.com> References: <200505061944.PAA29056@ietf.org> <0fb3601844cbf3e3999b0bf94bda49a2@innovationslab.net> <6.2.1.2.2.20050518170330.02c8bd40@mailhost.iprg.nokia.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: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Brian Haberman , IPv6 WG Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-11.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 Wed, 18 May 2005 17:14:46 -0700, >>>>> Bob Hinden said: >> - our implementation currently does NOT delay the response to an >> anycasted or multicasted query. > The question here is the delay useful. To me this would seem useful for > multicast queries, but I don't see the need for ones for anycast. I don't see the need (for anycast), either. In fact, in the case of anycast, the query packet should be delivered to a single responder only, and there should be no possibility of response collision which the delay would try to avoid. It should be noted that in the case of Neighbor Discovery (referred from the name-lookups draft in this context) a neighbor solicitation to an anycast address may be delivered to multiple nodes and there may be multiple neighbor advertisements. This scenario is very special and totally different from the name-lookups (or any other normal use of anycast) case. >> 1. In section 2, this document is too specific about particular >> implementations: >> >> [...] An example of a IPv6 debugging tool using IPv6 Node >> Information Queries is the ping6 program in the KAME, USAGI, and >> other IPv6 implementations . >> >> I'm afraid this is not very appropriate for a general specification >> document. Instead, we might say: > This was there purposely. At one point there was a lot of push back on > moving this forward and it was useful to be very specific about where this > was implemented and being used. Hmm, I do not necessarily oppose to keeping the specific implementation names (actually, I'd be honoured with that:-), if others (especially the IESG) accept this. >> 4. I'm afraid the reference to the MD5 spec (RFC1321) in Section 5 >> should be a normative reference in this context. (If >> icmp-name-lookups is expected to be published as a PS, this may >> cause a problem since RFC1321 is informational.) > I don't think that would be a problem. Do you mean it's okay to keep the reference informational? In any cast, I was actually just wondering, and I'd not oppose to the decision. >> 5. I don't see why we need the TTL field for Node Name, Node >> Addresses, and IPv4 Addresses if it MUST be always 0. Perhaps this >> is just for backward compatibility to existing implementations, >> though...(if so, I believe we should explicitly note that, since >> otherwise future readers will have the same question) > It is left for backward compatibility. I agree it would be good to explain > this. Okay. >> 7. Should we still need the "S" and "C" flags for the Node Addresses >> Query even though site-local unicast addresses and IPv4-compatible >> IPv6 addresses are now deprecated? > I think it is useful to leave them for backwards comparability. We might > want to add some text explaining this. Would it cause compatibility problem if we "reserved" those flag bits as "unused"? If we reserve the bits and specify the responder to ignore those bits, then the responder's behavior will be the same regardless of the semantics of the flags, since new responders wouldn't use these "deprecated" addresses in any event. So I personally think it's clearer to not include the now-deprecated notion in a new specification. But this is not a strong opinion. Unless others have particular opinions or preferences, I'll accept the editor's decision. 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 May 19 15:14:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqTX-0002Ln-UV; Thu, 19 May 2005 15:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqTV-0002Ld-EE for ipv6@megatron.ietf.org; Thu, 19 May 2005 15:14:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09601 for ; Thu, 19 May 2005 15:14:27 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYqkh-0003eK-Mq for ipv6@ietf.org; Thu, 19 May 2005 15:32:17 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:65cf:41f1:9582:c383]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DF85E15210; Fri, 20 May 2005 04:16:42 +0900 (JST) Date: Fri, 20 May 2005 04:15:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman In-Reply-To: References: <200505122000.QAA28547@ietf.org> 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@ietf.org Subject: Re: Forward: I-D ACTION:draft-ietf-ipv6-rfc2462bis-08.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 Sun, 15 May 2005 11:17:49 -0400, >>>>> Margaret Wasserman said: >> I've asked related questions about this comment on the wg list two >> times, including requested information at the Minneapolis meeting, but >> I've not got any responses...if this comment does not require any >> change to the document itself, I believe we are done. If it does, or >> if it requires any particular action (e.g., collecting implementation >> report), please clarify that. > It sounds like he document is ready, which is great, thanks! > It is up to the WG Chairs, Bob and Brian, to put together an > implementation report. In this particular case, this may only > involve pointing at the old implementation report and explaining why > the changes in this document do not warrant gathering further > implementation data. I will work with Bob and Brian on this. Cool, thanks. >> As I answered at this list, 2461bis and 2462bis should be updated at >> the same timing, so we'll eventually need to wait for 2461bis to be >> approved. If we reach the point, please just keep 2462bis sleeping >> for now. > Brian and Bob, what is the status on 2461bis? Are we expecting it to > be submitted for publication soon? 2461bis has passed the first wg last call. And, in my understanding, there were several non-trivial comments and we expect a new version addressing the comments before submitting the document to the IESG. As far as I can see, the comments were not so controversial, so I expect the next version will leave the wg. 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 May 19 16:32:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrhG-0003Of-CM; Thu, 19 May 2005 16:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrhF-0003Oa-3F for ipv6@megatron.ietf.org; Thu, 19 May 2005 16:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28112 for ; Thu, 19 May 2005 16:32:42 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYryR-0001QL-U1 for ipv6@ietf.org; Thu, 19 May 2005 16:50:33 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4JK1FB10321; Thu, 19 May 2005 13:01:15 -0700 X-mProtect: <200505192001> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpddW4Gcf; Thu, 19 May 2005 13:01:13 PDT Message-Id: <6.2.1.2.2.20050519132227.02bb9148@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 19 May 2005 13:32:12 -0700 To: Margaret Wasserman From: Bob Hinden In-Reply-To: References: <200505122000.QAA28547@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org Subject: Re: Forward: I-D ACTION:draft-ietf-ipv6-rfc2462bis-08.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 Margaret, >It is up to the WG Chairs, Bob and Brian, to put together an >implementation report. In this particular case, this may only involve >pointing at the old implementation report and explaining why the changes >in this document do not warrant gathering further implementation data. I >will work with Bob and Brian on this. Brian and I discussed this earlier today. We conclude that since this document is being recycled at Draft Standard and we are not making any incompatible changes, we don't think that new implementation reports are required. The current report is at: http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt We also encourage people who have implementations who are not listed, to submit one. They can use the existing reports as a template. >>As I answered at this list, 2461bis and 2462bis should be updated at >>the same timing, so we'll eventually need to wait for 2461bis to be >>approved. If we reach the point, please just keep 2461bis sleeping >>for now. > >Brian and Bob, what is the status on 2461bis? Are we expecting it to be >submitted for publication soon? Yes, we expect to submit it soon. While the two document are dependent on each other, we think it would be OK for the IESG to consider them sequentially. The reference dependances can be resolved in the RFC editor queue. To say it another way, we don't think there will be any changes to 2461bis that would require 2462bis to change. Thanks, Bob & Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 19 17:06:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYsDs-0005pB-RG; Thu, 19 May 2005 17:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYsDq-0005p3-ER for ipv6@megatron.ietf.org; Thu, 19 May 2005 17:06:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01307 for ; Thu, 19 May 2005 17:06:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYsV1-0002Pz-7m for ipv6@ietf.org; Thu, 19 May 2005 17:24:14 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4JKYti10589; Thu, 19 May 2005 13:34:55 -0700 X-mProtect: <200505192034> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdbtwAYH; Thu, 19 May 2005 13:34:53 PDT Message-Id: <6.2.1.2.2.20050519140024.02d7af88@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 19 May 2005 14:05:52 -0700 To: "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" From: Bob Hinden In-Reply-To: References: <200505061944.PAA29056@ietf.org> <0fb3601844cbf3e3999b0bf94bda49a2@innovationslab.net> <6.2.1.2.2.20050518170330.02c8bd40@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: b4a0a5f5992e2a4954405484e7717d8c Cc: IPv6 WG , Brian Haberman , Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-11.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 Jinmei, > > The question here is the delay useful. To me this would seem useful for > > multicast queries, but I don't see the need for ones for anycast. > >I don't see the need (for anycast), either. In fact, in the case of >anycast, the query packet should be delivered to a single responder >only, and there should be no possibility of response collision which >the delay would try to avoid. It should be noted that in the case of >Neighbor Discovery (referred from the name-lookups draft in this >context) a neighbor solicitation to an anycast address may be >delivered to multiple nodes and there may be multiple neighbor >advertisements. This scenario is very special and totally different >from the name-lookups (or any other normal use of anycast) case. I agree. > > This was there purposely. At one point there was a lot of push back on > > moving this forward and it was useful to be very specific about where this > > was implemented and being used. > >Hmm, I do not necessarily oppose to keeping the specific >implementation names (actually, I'd be honoured with that:-), if >others (especially the IESG) accept this. Yes, I think it will help. > >> 4. I'm afraid the reference to the MD5 spec (RFC1321) in Section 5 > >> should be a normative reference in this context. (If > >> icmp-name-lookups is expected to be published as a PS, this may > >> cause a problem since RFC1321 is informational.) > > > I don't think that would be a problem. > >Do you mean it's okay to keep the reference informational? In any >cast, I was actually just wondering, and I'd not oppose to the >decision. Sorry I wasn't clear. I don't think referencing MD5 will be a problem even if it is Informational. > >> 7. Should we still need the "S" and "C" flags for the Node Addresses > >> Query even though site-local unicast addresses and IPv4-compatible > >> IPv6 addresses are now deprecated? > > > I think it is useful to leave them for backwards comparability. We might > > want to add some text explaining this. > >Would it cause compatibility problem if we "reserved" those flag bits >as "unused"? If we reserve the bits and specify the responder to >ignore those bits, then the responder's behavior will be the same >regardless of the semantics of the flags, since new responders >wouldn't use these "deprecated" addresses in any event. So I >personally think it's clearer to not include the now-deprecated notion >in a new specification. But this is not a strong opinion. Unless >others have particular opinions or preferences, I'll accept the >editor's decision. I have a slight leaning for keeping it as is because of the existing implementations, but am happy to leave to the editor's discretion. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 19 18:45:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtlo-0002jU-Gu; Thu, 19 May 2005 18:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtlk-0002j3-CQ; Thu, 19 May 2005 18:45:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11237; Thu, 19 May 2005 18:45:29 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYu2y-0005CR-H2; Thu, 19 May 2005 19:03:21 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4JME6N01863; Thu, 19 May 2005 15:14:06 -0700 X-mProtect: <200505192214> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdxf0MSc; Thu, 19 May 2005 15:14:05 PDT Message-Id: <6.2.1.2.2.20050519154211.02c678a8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 19 May 2005 15:45:04 -0700 To: Thomas Narten From: Bob Hinden In-Reply-To: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> References: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dhcwg@ietf.org, IPv6 WG Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Thomas, >If the original 2461 text is really deemed insufficient, how about >something like: > > o M : > > 1-bit "Managed address configuration" flag. When set, it > indicates that addresses are available via Dynamic Host > Configuration Protocol [DHCPv6], including addresses that were > not configured via stateless address autoconfiguration. Clients > SHOULD use DHC to obtain addresses (and associated > configuration information) as described in [ADDRCONF]. Note > that when the M bit is set, the setting of the O bit is > irrelevant, since the DHC server will return "other" > configuration information together with addresses. > > o O : > > 1-bit "Other configuration" flag. When set, it indicates that > [DHCPv6lite] is available for autoconfiguration of other > (non-address) information. Examples of such information are > DNS-related information or information on other servers within > the network. When set, > > - If the M bit is also set, clients SHOULD use DHC to obtain > addresses (and associated configuration information) as > described above. > > - If the M bit is not set, clients SHOULD use DHC as > described in RFC 3736. > > >Is more than something like the above _really_ needed? If so, why? I agree and also don't see why more than this is needed. Thanks, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 03:18:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1mQ-0001lH-II; Fri, 20 May 2005 03:18:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ1mI-0001hR-Na; Fri, 20 May 2005 03:18:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14518; Fri, 20 May 2005 03:18:37 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ23c-0000sd-4h; Fri, 20 May 2005 03:36:32 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 44F5215218; Fri, 20 May 2005 16:20:50 +0900 (JST) Date: Fri, 20 May 2005 16:19:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.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: 10d3e4e3c32e363f129e380e644649be Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 (Cleaning the Cc list a bit) >>>>> On Wed, 18 May 2005 12:29:20 -0400, >>>>> Thomas Narten said: > There are really only two behaviors a client should be doing. If a > client doesn't implement DHC, well, then it obviously shouldn't/can't > invoke DHC. End of story. If it does implement DHC, well, it should > use it. Moreover, it shold never really be a "client" choice whether > to invoke use DHC or not. If the sys admin has stuff available via > DHC, the client should (in the SHOULD sense) be getting it and using > it. Why on earth would we want to disable that via a configuration > knob? One possible case would be a server host which manually configures itself with an IPv6 address, but seeks to get default router addresses via an RA and possibly other configuration information such as recursive DNS server addresses via DHCPv6 (Information-request/Reply). Such a host would receive (and use) RAs but not invoke DHCPv6 for address allocation even if the M flag is set in the RAs. I personally also expect a host that does not implement address allocation via DHCPv6 would have an implicit local policy that "disables" the behavior (regardless of the value of the M flag). But I admit the current mo-flags document does not clearly indicate that even if my expectation is reasonable. On the other hand, I'd also like to allow a client to use DHCPv6 (either full 3315 or the 3736 subset) even if the corresponding M or O flag is not set. In particular, I'd reserve the possibility for a host to try the RFC3736 behavior even if the O flag is off, so that the host can get configuration information even when the RA flags and available DHCPv6 are inconsistent (due to misconfiguration of routers, etc). > So, these bits should just provide clients with a stronger indication > that they should be using DHC to get the information that is > available. In general, I agree (while I'd say "...that they can be using DHC ..."). > Is more than something like the above _really_ needed? If so, why? "_really_" sounds subjective, and opinions may vary, but I personally don't think "the above" is enough in practice. In my understanding, many people have been confused about the relationship between the M/O flags and the "stateful" configuration protocol (we now know the protocol is DHCPv6). At least I, as an implementor, have been always confused about these points. For example, 1. whether the specification about the M flag indicates address allocation via DHCPv6 is a mandatory feature to be implemented in hosts. (this point may now be clear by the "IPv6 Node Requirements" document and recent clarification of 2462bis) 2. whether it's valid for a host to not invoke DHCPv6 (either full RFC3315 or the RFC3736 subset) even if the corresponding M/O flag is set. (see above) 3. whether it's valid for a host to do invoke DHCPv6 (either full RFC3315 or the RFC3736 subset) even if the corresponding M/O flag is not set. (see also above) 4. what should the host do if the M or O flag is reset from ON to OFF. (while I pernsoally believe RFC2462 is pretty clear on this, many people, including a DHCPv6 specialist, have still misunderstood that.) 5. what if the M flag is set but the host does not get any DHCPv6 Advertise in the initial exchange? Is it okay to fall back to the RFC3736 subset? Or is it even okay to run both full RFC3315 and the RFC3736 subset concurrently from the beginning? If all we have is "the above" you suggested or the current 2461bis wording, I'd still continue getting confused. So I personally want to clarify these points somewhere, either in an existing document or a separate document like the ra-mo-flags draft. As for the latter, I don't stick to the current content. Perhaps sections 6 and 7 are overspecification, and I'll be happy as long as we can clarify the points that have confused many people so far. According to the others' opinions, however, all or some of the above points seem to be so trivial to some people that they don't bother to "clarify" those. If I've been simply dull and things are so clear for others, I don't mind killing the new clarification document (it would reduce my responsibility:-). 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 May 20 04:25:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2pM-0000Bz-LY; Fri, 20 May 2005 04:25:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2pG-00009Y-6E; Fri, 20 May 2005 04:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19701; Fri, 20 May 2005 04:25:43 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ36Z-0002gw-Hk; Fri, 20 May 2005 04:43:40 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGS00GU24QM67@mailout2.samsung.com>; Fri, 20 May 2005 17:25:34 +0900 (KST) Received: from SYAM ([107.108.71.89]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IGS0043D4QC0H@mmp1.samsung.com>; Fri, 20 May 2005 17:25:34 +0900 (KST) Date: Fri, 20 May 2005 13:53:34 +0530 From: Syam Madanapalli To: Thomas Narten Message-id: <008701c55d15$3c287d30$59476c6b@sisodomain.com> 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; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 5/18/05, Thomas Narten wrote: > Let me just start off by saying I pretty much agree completely with > what Bernie just said. Even I do agrre, what Bernie said. I understodd from his mail, a node can fall back to Information Configuration Behavior (DHCPv6 Lite) if ti fails do Full DHCP. I am not sure if such infomation is available in handy somewhere. Moreless the draft looks similar to what Bernie said except with more options to control the invoking th DHCPv6 behaviour, e.g., If I know prettty sure that the DHCPv6 is not avaialble in the network my node is connected, I have not seen any reason why I should let DHCPv6 be running in the background. > > I've also reviewed this document, and I am really wondering what this > document is trying to achieve. It seems to me that its added a lot of > text (that IMO is not really needed). In particular, I don't think > either Section 6 or 7 are necessary or appropriate. > > There are really only two behaviors a client should be doing. If a > client doesn't implement DHC, well, then it obviously shouldn't/can't > invoke DHC. End of story. If it does implement DHC, well, it should > use it. Moreover, it shold never really be a "client" choice whether > to invoke use DHC or not. If the sys admin has stuff available via > DHC, the client should (in the SHOULD sense) be getting it and using > it. Why on earth would we want to disable that via a configuration > knob? If it is this simple, we do not really need the M/O flags in Router Advertisements. > > Indeed, when I look at Section 2, "Background", I find that the > wording that it quotes from RFC 2461 really does say pretty much what > should be said. That is, these bits are "hints" that the local sys > admin has a DHC server that is giving out addresses and/or other > configuration information. Seems to me, if the local access network is > giving out config information, clients SHOULD try and get it, because > if they don't, they will presumably operate at some sort of reduced > level of functionality -- after all, if a sys admin set up a DHC > server, there must be a reason for this (e.g., to provide DNS > recursive name server service, addresses not available via stateless > addrconf, etc.). Also it is not clear for nodes what they should if they receive these bits ON to OFF and vise versa. > > So, these bits should just provide clients with a stronger indication > that they should be using DHC to get the information that is > available. > > > If the original 2461 text is really deemed insufficient, how about > something like: > > o M : > > 1-bit "Managed address configuration" flag. When set, it > indicates that addresses are available via Dynamic Host > Configuration Protocol [DHCPv6], including addresses that were > not configured via stateless address autoconfiguration. Clients > SHOULD use DHC to obtain addresses (and associated > configuration information) as described in [ADDRCONF]. Note > that when the M bit is set, the setting of the O bit is > irrelevant, since the DHC server will return "other" > configuration information together with addresses. > > o O : > > 1-bit "Other configuration" flag. When set, it indicates that > [DHCPv6lite] is available for autoconfiguration of other > (non-address) information. Examples of such information are > DNS-related information or information on other servers within > the network. When set, > > - If the M bit is also set, clients SHOULD use DHC to obtain > addresses (and associated configuration information) as > described above. > > - If the M bit is not set, clients SHOULD use DHC as > described in RFC 3736. > > > Is more than something like the above _really_ needed? If so, why? Currently for IPv4, we either select to get the address using DHCP, or configure manually. At least this true in Windows OS. Similarly, it is not bad idea to have options for IPv6 to select between DHCPv6, SLAAC or Manual or combination of these. For an intelligent use he can furthe select options for DHCPv6 either to run all the time or run only when host sees the M/O flag set. THis is what the policy the draft is talking about. Of course I do agree that it it little heavy in the current form, which can be simplified. I think it is worth clarifing these, and in any case the draft is not going to introduce any changes to the existing standards. > > Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 06:45:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ50X-0000Mz-SN; Fri, 20 May 2005 06:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ50U-0000LB-G7; Fri, 20 May 2005 06:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29329; Fri, 20 May 2005 06:45:27 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ5Hp-0005lc-Of; Fri, 20 May 2005 07:03:26 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 20 May 2005 03:45:21 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4KAjFnE027792; Fri, 20 May 2005 03:45:18 -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); Fri, 20 May 2005 06:45:17 -0400 Received: from 10.86.242.191 ([10.86.242.191]) 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 ; Fri, 20 May 2005 10:45:16 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 06:45:37 -0400 From: Ralph Droms To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2005 06:37:55 -0400 Message-Id: <1116585475.7812.43.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 10:45:17.0351 (UTC) FILETIME=[02E4AB70:01C55D29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Comments in line... - Ralph On Fri, 2005-05-20 at 16:19 +0900, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: > (Cleaning the Cc list a bit) >=20 > >>>>> On Wed, 18 May 2005 12:29:20 -0400,=20 > >>>>> Thomas Narten said: >=20 > > There are really only two behaviors a client should be doing. If a > > client doesn't implement DHC, well, then it obviously shouldn't/can't > > invoke DHC. End of story. If it does implement DHC, well, it should > > use it. Moreover, it shold never really be a "client" choice whether > > to invoke use DHC or not. If the sys admin has stuff available via > > DHC, the client should (in the SHOULD sense) be getting it and using > > it. Why on earth would we want to disable that via a configuration > > knob? >=20 > One possible case would be a server host which manually configures > itself with an IPv6 address, but seeks to get default router addresses > via an RA and possibly other configuration information such as > recursive DNS server addresses via DHCPv6 (Information-request/Reply). > Such a host would receive (and use) RAs but not invoke DHCPv6 for > address allocation even if the M flag is set in the RAs. There's no particular reason why a host with an otherwise configured address might not also use DHCP for other assigned addresses. But, I agree with you that use of DHCP in a host is a matter of local policy, perhaps guided by the M/O bits. > I personally also expect a host that does not implement address > allocation via DHCPv6 would have an implicit local policy that > "disables" the behavior (regardless of the value of the M flag). But > I admit the current mo-flags document does not clearly indicate that > even if my expectation is reasonable. This local policy seems to be a crucial issue. Do we try to describe host behavior explicitly or do we specify the network behavior (M/O bits; retransmit behavior for ND and DHCP; HCB/ICB (Host Configuration Behavior [RFC 3315]/Information Configuration Behavior [RFC 3736] information returned from DHCP server) and leave the host to implement its own policy and behavior? > On the other hand, I'd also like to allow a client to use DHCPv6 > (either full 3315 or the 3736 subset) even if the corresponding M or O > flag is not set. In particular, I'd reserve the possibility for a > host to try the RFC3736 behavior even if the O flag is off, so that > the host can get configuration information even when the RA flags and > available DHCPv6 are inconsistent (due to misconfiguration of routers, > etc). I don't see a reason to prohibit explicitly use of DHCP is M/O bits are not set. Other standards bodies or host implementors may choose to make such prohibitions if appropriate; e.g., in a network environment with limited bandwidth where any spurious traffic is avoided. > > So, these bits should just provide clients with a stronger indication > > that they should be using DHC to get the information that is > > available. >=20 > In general, I agree (while I'd say "...that they can be using DHC > ..."). >=20 > > Is more than something like the above _really_ needed? If so, why? >=20 > "_really_" sounds subjective, and opinions may vary, but I personally > don't think "the above" is enough in practice. In my understanding, > many people have been confused about the relationship between the M/O > flags and the "stateful" configuration protocol (we now know the > protocol is DHCPv6). At least I, as an implementor, have been always > confused about these points. For example, >=20 > 1. whether the specification about the M flag indicates address > allocation via DHCPv6 is a mandatory feature to be implemented in > hosts. (this point may now be clear by the "IPv6 Node > Requirements" document and recent clarification of 2462bis) I agree that the requirement for DHCP has never been entirely clear nor well-documented. > 2. whether it's valid for a host to not invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is set. (see above) > 3. whether it's valid for a host to do invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is not set. (see also above) If there is confusion about these points, then we need clarification, once we agree on the desired behavior and definition. > 4. what should the host do if the M or O flag is reset from ON to OFF. > (while I pernsoally believe RFC2462 is pretty clear on this, many > people, including a DHCPv6 specialist, have still misunderstood > that.) RFC 2462 is pretty clear; however, I must admit I have been confused by the lengthy discussion clarifying the meaning of the bits and I seem to remember that there was a proposal to change the meaning of the bits at some point in the discussion. > 5. what if the M flag is set but the host does not get any DHCPv6 > Advertise in the initial exchange? Is it okay to fall back to the > RFC3736 subset? Or is it even okay to run both full RFC3315 and > the RFC3736 subset concurrently from the beginning? There is another possibility - a DHCP server that will not assign addresses can respond to a Solicit message with an appropriate status code. Thus, a host that tries to use HCB first can get an immediate indication that HCB is not available and revert to ICB immediately. Deployment of such behavior may require some clarification in the DHCP RFCs, because the existence of two separate RFCs has led to confusion about the "separation" of two "different" protocols for HCB and ICB. There is no *prohibition* against a DHCP server that intends to participate only in ICB from responding to a Solicit message with the "will not assign addresses" ("NoAddrsAvail")._DOa. Additionally, a small, backward-compatible extension to RFC 3315 would simplify the situation even further. At present, RFC 3315 specifies that a server return the NoAddrsAvail status code and no other information. If the server were allowed to return NoAddrsAvail *and* ICB options, the host could use the ICB options with a simple 2-message exchange. This extension would also require a clarification to RFC 3736 explicitly allowing this behavior (Note that RFC 3736 is intended as *minimum* function and does not *prohibit* implementation of other DHCP features). > If all we have is "the above" you suggested or the current 2461bis > wording, I'd still continue getting confused. So I personally want to > clarify these points somewhere, either in an existing document or a > separate document like the ra-mo-flags draft. As for the latter, I > don't stick to the current content. Perhaps sections 6 and 7 are > overspecification, and I'll be happy as long as we can clarify the > points that have confused many people so far. >=20 > According to the others' opinions, however, all or some of the above > points seem to be so trivial to some people that they don't bother to > "clarify" those. If I've been simply dull and things are so clear for > others, I don't mind killing the new clarification document (it would > reduce my responsibility:-). >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp In my opinion, we need a simple clarification of M/O bits as "advisory" and that there is no explicit *restriction* on hosts' use of DHCP. We might also consider a couple of clarifications and minor extensions to the DHCP spec to optimize host-server interaction. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 07:39:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ5qT-0002vi-Ot; Fri, 20 May 2005 07:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ5qS-0002va-0b; Fri, 20 May 2005 07:39:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03397; Fri, 20 May 2005 07:39:10 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ67o-000719-3H; Fri, 20 May 2005 07:57:08 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 07:39:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KBcQeS004160; Fri, 20 May 2005 07:39:00 -0400 (EDT) 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); Fri, 20 May 2005 07:38:59 -0400 Received: from 10.86.242.191 ([10.86.242.191]) 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 ; Fri, 20 May 2005 11:38:59 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 07:39:19 -0400 From: Ralph Droms To: dhcwg@ietf.org, IPv6 WG In-Reply-To: References: <8E296595B6471A4689555D5D725EBB212B33DE@xmb-rtp-20a.amer.cisco.com> <200505181629.j4IGTKmt005705@cichlid.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 07:39:19 -0400 Message-Id: <1116589159.7812.70.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 11:38:59.0747 (UTC) FILETIME=[83974730:01C55D30] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 The discussion of M/O bits caused me to think about the meaning and specification of host behavior for M/O bits and for SLAAC. In particular, I'm trying to understand the degree of control over host behavior specified in both cases. I'll focus here on what I can understand about SLAAC, because we've been discussing the M/O bits in a separate thread. One part of the specification in section 5.5 of RFC 2462 seems pretty clear: 5.5. Creation of Global and Site-Local Addresses [...] Creation of global and site-local addresses and configuration of other parameters as described in this section SHOULD be locally configurable. However, the processing described below MUST be enabled by default. I read this to mean that the information in the RAs is advisory. In section 5.5.3 of RFC 2462, the following text seems to imply that the "autonomous address-configuration flag" (A bit) controls whether a host forms a SLAAC address for a prefix: a) If the Autonomous flag is not set, silently ignore the Prefix Information option. But, there is no RFC 2119 language, and the earlier text allows for local host configuration, so it's not clear if a host is compliant with RFC 2462 if it forms a SLAAC address from a prefix advertised with the A-bit not set. Later in the same list of behaviors: d) If the prefix advertised does not match the prefix of an address already in the list, and the Valid Lifetime is not 0, form an address (and add it to the list) [...] This text also does not contain RFC 2119 language, so it's not clear that a host is required to form an SLAAC address from a prefix advertised with the A-bit set. While open to interpretation, I read the text about SLAAC addresses to be advisory, which would give roughly the same control over host behavior as interpreting the M/O bits as indicating the availability of DHCP services, but not requiring specific behavior on the part of hosts. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 13:09:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAzv-0004kY-F9; Fri, 20 May 2005 13:09:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAzu-0004kT-H8 for ipv6@megatron.ietf.org; Fri, 20 May 2005 13:09:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08726 for ; Fri, 20 May 2005 13:09:15 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBHG-00081g-A0 for ipv6@ietf.org; Fri, 20 May 2005 13:27:17 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4KGbn005184; Fri, 20 May 2005 09:37:49 -0700 X-mProtect: <200505201637> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdbCf7yL; Fri, 20 May 2005 09:37:48 PDT Message-Id: <6.2.1.2.2.20050520095504.02c65808@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 20 May 2005 10:08:50 -0700 To: IPv6 WG From: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Brian Haberman , Bob Hinden Subject: Update to 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 To clear what we hope is the last IESG "Discuss" comment on this document, the AD's plan to add a note after the third paragraph in the Introduction section (that starts with "This document describes an optional extension to Neighbor Discovery Router Advertisement messages.....") as an RFC-Editor note. The text is: Note that since these procedures are applicable to hosts only, the forwarding algorithm used by the routers (including hosts with enabled IP forwarding) is not affected. We wanted to pass this by the working group to see if any objects to this change. We think the additional text is fine. Thanks, Bob Hinden and Brian Haberman -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 13:24:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBEt-0001vI-4j; Fri, 20 May 2005 13:24:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBEq-0001vD-Rf for ipv6@megatron.ietf.org; Fri, 20 May 2005 13:24:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10588 for ; Fri, 20 May 2005 13:24:39 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBWB-0008WS-Kd for ipv6@ietf.org; Fri, 20 May 2005 13:42:41 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHOROL017932 for ; Fri, 20 May 2005 13:24:27 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KHORYV118008 for ; Fri, 20 May 2005 13:24:27 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KHORFn014968 for ; Fri, 20 May 2005 13:24:27 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHOQdu014964 for ; Fri, 20 May 2005 13:24:27 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KHOQ0j022198 for ; Fri, 20 May 2005 13:24:26 -0400 Message-Id: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> To: ipv6@ietf.org Date: Fri, 20 May 2005 13:24:26 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: meta thoughts on m/o bits 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 Stepping up a level (and this also reflects my thinking after a private exchange with Ralph/Bernie - but not necessarily their thinking!)... I think the M/O bits (in retrospect) have turned out to be more trouble than they are worth. Indeed, they seem to be mostly just confusing. Thus, maybe we should work towards removing them completely. In an ideal world, there would be exactly one way for a client to invoke DHC. That is, it would use the same message exchange to get "addresses" as it did for "non-address configuration". In such a world, there would be no need for the M/O bits, since the client would do the same thing if either one of them were set. Unfortunately, we are not quite there, since DHC actually has HCB & ICB message exchanges (using Ralph's terminology). Thus, there are scenarios where invoking ICB is preferable over HCB. (Aside note: here is another example where having two ways to do similar things, results in undesirable complexity). Currently, we sort of need the M/O bits so a client can know which variant of DHC to invoke. But, we now also allow for the possibility of "silly states", i.e., states that aren't supposed to happen, but can, e.g., through misconfiguration. Having the M bit set but no addresses available is one such example. Ralph has already indicated that with some small changes to the DHC spec, we might be able to fix the DHC issue so that there is one way to invoke DHC that does the right thing in all combinations of addresses and/or other configuration information being available via DHC. If we had that, we wouldn't need two RA bits anymore. At most, a single "there is stuff to obtain via DHC" bit would suffice. Indeed, one could go further and say "just always invoke DHC", and don't even bother with an RA bit saying DHC is available. That has the nice property of being simple to implement and you don't have silly states where the RA bit(s) are configured incorrectly, etc. The only advantage I can see right off to having at least 1 RA bit is to tell the client "there is no DHC server running, so don't even bother". This would be a performance optimization to allow one to avoid needing to invoke DHC and have it timeout -- before concluding that there are no DHC servers. Is this a significant optimization? Hard to say. What I would like to suggest: followup on the above proposed DHC changes and see if we can actually "fix" DHC to simplify what the client has to do to invoke it. And if that works, do away with one or both of the RA bits. Remember, simplicity is Good! Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 13:47:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBag-0007Zm-Mi; Fri, 20 May 2005 13:47:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBad-0007Xp-CY for ipv6@megatron.ietf.org; Fri, 20 May 2005 13:47:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15475 for ; Fri, 20 May 2005 13:47:14 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBs1-000117-HY for ipv6@ietf.org; Fri, 20 May 2005 14:05:14 -0400 Received: by rproxy.gmail.com with SMTP id a41so517483rng for ; Fri, 20 May 2005 10:47:10 -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:content-transfer-encoding:content-disposition:references; b=LX4eszt2iITItF1Ovam1ufgP2LTj8+CqzogKfDeh+ntziEDsnTvVs238aug7wlLZd2YnSQE2V4SqbOsST7bbnwH7qYdLsDTjk8nrlstyr8/jDnZx+Vg1puw561k3gVgN8XbhNCstdPfLnZxEehCE8cpaRXJST8X71G3HcQdm3dM= Received: by 10.38.67.20 with SMTP id p20mr1908793rna; Fri, 20 May 2005 10:47:10 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Fri, 20 May 2005 10:47:09 -0700 (PDT) Message-ID: <10e14db205052010473cfbbbdb@mail.gmail.com> Date: Fri, 20 May 2005 23:17:09 +0530 From: Syam Madanapalli To: Thomas Narten In-Reply-To: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: meta thoughts on m/o bits X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Syam Madanapalli 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 proposal looks better and easy to understand. However, if we just rely on timeout for concluding the unavailabiliy of DHCP server, how does the client re-invoke DHCP if the DHCP server is available later in= =20 time? I think we need one bit to inform the clients about the availabilty of DHCP services in the network. On 5/20/05, Thomas Narten wrote: > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... >=20 > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. >=20 > In an ideal world, there would be exactly one way for a client to > invoke DHC. That is, it would use the same message exchange to get > "addresses" as it did for "non-address configuration". In such a > world, there would be no need for the M/O bits, since the client would > do the same thing if either one of them were set. >=20 > Unfortunately, we are not quite there, since DHC actually has HCB & > ICB message exchanges (using Ralph's terminology). Thus, there are > scenarios where invoking ICB is preferable over HCB. (Aside note: here > is another example where having two ways to do similar things, results > in undesirable complexity). Currently, we sort of need the M/O bits so > a client can know which variant of DHC to invoke. But, we now also > allow for the possibility of "silly states", i.e., states that aren't > supposed to happen, but can, e.g., through misconfiguration. Having > the M bit set but no addresses available is one such example. >=20 > Ralph has already indicated that with some small changes to the DHC > spec, we might be able to fix the DHC issue so that there is one way > to invoke DHC that does the right thing in all combinations of > addresses and/or other configuration information being available via > DHC. >=20 > If we had that, we wouldn't need two RA bits anymore. At most, a > single "there is stuff to obtain via DHC" bit would suffice. >=20 > Indeed, one could go further and say "just always invoke DHC", and > don't even bother with an RA bit saying DHC is available. That has the > nice property of being simple to implement and you don't have silly > states where the RA bit(s) are configured incorrectly, etc. >=20 > The only advantage I can see right off to having at least 1 RA bit is > to tell the client "there is no DHC server running, so don't even > bother". This would be a performance optimization to allow one to > avoid needing to invoke DHC and have it timeout -- before concluding > that there are no DHC servers. Is this a significant optimization? > Hard to say. >=20 > What I would like to suggest: followup on the above proposed DHC > changes and see if we can actually "fix" DHC to simplify what the > client has to do to invoke it. And if that works, do away with one or > both of the RA bits. >=20 > Remember, simplicity is Good! >=20 > Thomas >=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 Fri May 20 13:47:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBb6-0007fU-P6; Fri, 20 May 2005 13:47:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBb4-0007fH-JW; Fri, 20 May 2005 13:47:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15498; Fri, 20 May 2005 13:47:41 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBsT-00011j-OZ; Fri, 20 May 2005 14:05:42 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHlQNG021138; Fri, 20 May 2005 13:47:27 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KHlQi4153890; Fri, 20 May 2005 13:47:26 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KHlQ1x017046; Fri, 20 May 2005 13:47:26 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHlQtU017035; Fri, 20 May 2005 13:47:26 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KHlPAm022320; Fri, 20 May 2005 13:47:25 -0400 Message-Id: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message from jinmei@isl.rdc.toshiba.co.jp of "Fri, 20 May 2005 16:19:26 +0900." Date: Fri, 20 May 2005 13:47:25 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > One possible case would be a server host which manually configures > itself with an IPv6 address, but seeks to get default router addresses > via an RA and possibly other configuration information such as > recursive DNS server addresses via DHCPv6 (Information-request/Reply). > Such a host would receive (and use) RAs but not invoke DHCPv6 for > address allocation even if the M flag is set in the RAs. There is nothing wrong with the above case. But, I don't think we need our specs need to say anything about them either. There are always going to be lots of scenarios where a vendor may want to do things differently than implement _only_ what the spec says _explicitely_. Thus, I see no reason to go into a lot of detail in one our specs supporting this particular scenario or "allowing" it to be "part of the standard" so to speak. That is, vendors always implement additional knobs/whistles as they see fit. The IETF doesn't need to account for all of those. What we our specs do need to support is not disallowing behavior that it might make sense to allow for, and that doesn't negatively impact interoperability and such. The above should be perfectly consistent with our existing specs. Do you (or others) feel otherwise? I.e., is the above not allowed by our specs? > I personally also expect a host that does not implement address > allocation via DHCPv6 would have an implicit local policy that > "disables" the behavior (regardless of the value of the M flag). But > I admit the current mo-flags document does not clearly indicate that > even if my expectation is reasonable. I do not understand the concept of having a local policy that disables invoking a service that one has not implemented. If you don't implement it you don't implement it, and anywhere you might consider invoking the service, well, you obviously just don't. That is not a "local policy", that is just common sense. :-) It has never been the case that if something is not in an IETF spec, it is "disallowed" or "not compliant" with a spec. If we go down that road, one ends up having to overspecify everything to make sure even obvious things are allowed. What our specs _do_ need to do is be very clear on what we expect all implementations to do, in order to achieve interoberability (and to prevent damaging behavior, as in, e.g., being congestion unfriendly). > On the other hand, I'd also like to allow a client to use DHCPv6 > (either full 3315 or the 3736 subset) even if the corresponding M or O > flag is not set. I agree that this should be allowed. Indeed, I'd expect that to be the default behavior regardless of the M/O bits. It should be the default behavior of anyone that implements DHC. No where in our specs (AFAIK) is it claimed that you SHOULD/MUST NOT invoke DHC if the M/O bits are clear. Right? > In particular, I'd reserve the possibility for a > host to try the RFC3736 behavior even if the O flag is off, so that > the host can get configuration information even when the RA flags and > available DHCPv6 are inconsistent (due to misconfiguration of routers, > etc). Is there any wording in our specs that suggests a client is not allowed to invoke DHC if either of the M or O bit is off? If not, why do people feel that they are not allowed to invoke DHC? > "_really_" sounds subjective, and opinions may vary, but I personally > don't think "the above" is enough in practice. In my understanding, > many people have been confused about the relationship between the M/O > flags and the "stateful" configuration protocol (we now know the > protocol is DHCPv6). At least I, as an implementor, have been always > confused about these points. For example, > 1. whether the specification about the M flag indicates address > allocation via DHCPv6 is a mandatory feature to be implemented in > hosts. (this point may now be clear by the "IPv6 Node > Requirements" document and recent clarification of 2462bis) The RA bits should have no bearing in answering that question. They are advisory only. I think folk have already made it clear that DHC on clients is not "mandatory to implement as part of IPv6". If that is the question you really have, this document is the wrong way to ask/resolve it. Another way of looking at things. Does the fact that someone can send a node a TCP SYN packet require (in the MUST sense) that the client respond to that SYN? Likewise, if an RA says "DHC is available", that doesn't mandate that it invoke DHC either. (but the node SHOULD do so...) > 2. whether it's valid for a host to not invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is set. (see above) That is why I suggested "SHOULD invoke DHC". Makes it clear you should, but there are cases where you might not want to, so no, it is not mandatory to _invoke_ (mandatory to implement is covered in the previous question). > 3. whether it's valid for a host to do invoke DHCPv6 (either full > RFC3315 or the RFC3736 subset) even if the corresponding M/O flag > is not set. (see also above) should be, IMO. The bits do not mean "if 0, you MUST NOT use DHC ..." > 4. what should the host do if the M or O flag is reset from ON to OFF. > (while I pernsoally believe RFC2462 is pretty clear on this, many > people, including a DHCPv6 specialist, have still misunderstood > that.) On to off? nothing. Let DHC continue to be used. The DHC protocol will do what it normally does if a DHC server goes away... I.e., if you've gotten config information from DHC that still has a valide lifetime, you wouldn't throw that information away... > 5. what if the M flag is set but the host does not get any DHCPv6 > Advertise in the initial exchange? Is it okay to fall back to the > RFC3736 subset? Or is it even okay to run both full RFC3315 and > the RFC3736 subset concurrently from the beginning? Should be legal, but this is an unfortunate situation, since we're not trying getting into how to deal with misconfigurations... Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 13:53:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBh6-0000P6-Ef; Fri, 20 May 2005 13:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBh4-0000OU-Na for ipv6@megatron.ietf.org; Fri, 20 May 2005 13:53:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16184 for ; Fri, 20 May 2005 13:53:53 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZByS-0001EU-Eo for ipv6@ietf.org; Fri, 20 May 2005 14:11:54 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4KHrgcE272584 for ; Fri, 20 May 2005 13:53:42 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KHrgwj253212 for ; Fri, 20 May 2005 11:53:42 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4KHrgg9031667 for ; Fri, 20 May 2005 11:53:42 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4KHrfIF031632; Fri, 20 May 2005 11:53:41 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KHreXo022341; Fri, 20 May 2005 13:53:40 -0400 Message-Id: <200505201753.j4KHreXo022341@rotala.raleigh.ibm.com> To: Syam Madanapalli In-Reply-To: Message from smadanapalli@gmail.com of "Fri, 20 May 2005 23:17:09 +0530." <10e14db205052010473cfbbbdb@mail.gmail.com> Date: Fri, 20 May 2005 13:53:40 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org Subject: Re: meta thoughts on m/o bits 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 proposal looks better and easy to understand. However, > if we just rely on timeout for concluding the unavailabiliy of DHCP server, > how does the client re-invoke DHCP if the DHCP server is available later in > time? I think we need one bit to inform the clients about the > availabilty of DHCP > services in the network. I would assume that DHC has mechanisms for discovering when DHC servers come on line. I.e., the client just sits quietly in background. Sure, an RA bit could also signal the availability of a new server, but I would first like to be convinced that the existing default DHC mechanism isn't good enough for handling this case (better not to have multiple ways of acheiving the same result). Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 14:07:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBuQ-0006Ks-P0; Fri, 20 May 2005 14:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZBuN-0006KO-Gf for ipv6@megatron.ietf.org; Fri, 20 May 2005 14:07:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18202 for ; Fri, 20 May 2005 14:07:38 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCBl-0001hv-Ua for ipv6@ietf.org; Fri, 20 May 2005 14:25:39 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 14:07:26 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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, 20 May 2005 14:06:24 -0400 Message-ID: Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdZRdKRkzX96osRHqLKLGXEqVwGQAAX0Qg From: "Soliman, Hesham" To: "Thomas Narten" , "Syam Madanapalli" X-OriginalArrivalTime: 20 May 2005 18:07:26.0820 (UTC) FILETIME=[C7B06240:01C55D66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: meta thoughts on m/o bits 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 proposal looks better and easy to understand. However, > > if we just rely on timeout for concluding the=20 > unavailabiliy of DHCP server, > > how does the client re-invoke DHCP if the DHCP server is=20 > available later in=20 > > time? I think we need one bit to inform the clients about the > > availabilty of DHCP > > services in the network. >=20 > I would assume that DHC has mechanisms for discovering when DHC > servers come on line. I.e., the client just sits quietly in=20 > background. =3D> I'm curious about this, does DHCP broadcast its existence to clients that never used it when it comes up? Seems a bit strange to do that. I don't even know how it could speak to a client = unsolicited. Hesham >=20 > Sure, an RA bit could also signal the availability of a new server, > but I would first like to be convinced that the existing default DHC > mechanism isn't good enough for handling this case (better=20 > not to have > multiple ways of acheiving the same result). >=20 > Thomas >=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 May 20 14:25:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCBu-0003Bi-Fo; Fri, 20 May 2005 14:25:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCBp-0003Bd-IW for ipv6@megatron.ietf.org; Fri, 20 May 2005 14:25:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20262 for ; Fri, 20 May 2005 14:25:40 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCTD-0002HL-6N for ipv6@ietf.org; Fri, 20 May 2005 14:43:41 -0400 Received: by rproxy.gmail.com with SMTP id a41so528326rng for ; Fri, 20 May 2005 11:25:38 -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:content-transfer-encoding:content-disposition:references; b=KDO4zmiHitV/c0MoyTWGqvo9KM13omC/o+3SpMz2qbFv9ky3/7mCuJWStjHJUw2KB6vw+QQE9+XKsHtmzbpkTtHK99Ps1/GUa8ghpecw6733oPeEBXjdqRXCuZ4UhEV5OJSLNrqbJWPNgVMmyrgod9Zbk/IuyyPQnI3C+3uFYRU= Received: by 10.38.74.69 with SMTP id w69mr1937928rna; Fri, 20 May 2005 11:25:38 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Fri, 20 May 2005 11:25:38 -0700 (PDT) Message-ID: <10e14db2050520112534c4dadc@mail.gmail.com> Date: Fri, 20 May 2005 23:55:38 +0530 From: Syam Madanapalli To: "Soliman, Hesham" 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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , dhc@ietf.org, ipv6@ietf.org Subject: Re: meta thoughts on m/o bits X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Syam Madanapalli 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 5/20/05, Soliman, Hesham wrote: >=20 > > > This proposal looks better and easy to understand. However, > > > if we just rely on timeout for concluding the > > unavailabiliy of DHCP server, > > > how does the client re-invoke DHCP if the DHCP server is > > available later in > > > time? I think we need one bit to inform the clients about the > > > availabilty of DHCP > > > services in the network. > > > > I would assume that DHC has mechanisms for discovering when DHC > > servers come on line. I.e., the client just sits quietly in > > background. >=20 > =3D> I'm curious about this, does DHCP broadcast its existence to > clients that never used it when it comes up? Seems a bit strange > to do that. I don't even know how it could speak to a client unsolicited. >=20 Yes, I do not think there is any message that has currently been defined in DHCP, that the servers broadcast without client solicitation. > Hesham >=20 > > > > Sure, an RA bit could also signal the availability of a new server, > > but I would first like to be convinced that the existing default DHC > > mechanism isn't good enough for handling this case (better > > not to have > > multiple ways of acheiving the same result). > > > > Thomas > > > > -------------------------------------------------------------------- > > 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 stri= ctly > prohibited. If you are not the intended recipient please contact the se= nder > 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 > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 14:33:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCJB-0004ZW-Gf; Fri, 20 May 2005 14:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCJ9-0004ZR-Sc for ipv6@megatron.ietf.org; Fri, 20 May 2005 14:33:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21126 for ; Fri, 20 May 2005 14:33:14 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCaY-0002Vy-J0 for ipv6@ietf.org; Fri, 20 May 2005 14:51:15 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KIX57A029279; Fri, 20 May 2005 14:33:05 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KIX5i4133920; Fri, 20 May 2005 14:33:05 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KIX48H011168; Fri, 20 May 2005 14:33:04 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KIX4EC011091; Fri, 20 May 2005 14:33:04 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KIX0Lr022951; Fri, 20 May 2005 14:33:00 -0400 Message-Id: <200505201833.j4KIX0Lr022951@rotala.raleigh.ibm.com> To: Syam Madanapalli In-Reply-To: Message from smadanapalli@gmail.com of "Fri, 20 May 2005 23:55:38 +0530." <10e14db2050520112534c4dadc@mail.gmail.com> Date: Fri, 20 May 2005 14:33:00 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Soliman, Hesham" , dhc@ietf.org, ipv6@ietf.org Subject: Re: meta thoughts on m/o bits 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'm curious about this, does DHCP broadcast its existence to > > clients that never used it when it comes up? Seems a bit strange > > to do that. I don't even know how it could speak to a client unsolicited. > > > Yes, I do not think there is any message that has currently been defined > in DHCP, that the servers broadcast without client solicitation. There are generally two ways to discover the existance of a server: - broadcast its existance (e.g., via a DHC broadcast or RA "DHC server present" bit) - have clients periodically poll the server Each has different tradeoffs in terms of timeliness of discovering the server vs. load on the network, etc. Those assuming a broadcast mechanism is needed may be making the assumption that if an admin turns on a DHC server, it is a _requirement_ that all nodes start using DHC effectively _immediately_. It is not at all clear to me that this is a requirement. I.e., it might be just fine to have all clients learn of DHC within say 1-2 hours (if not longer), in which case background polling is just fine. Remember, I don't think we're necessarily talking about the case where a DHC server goes down. We're presumably talking about the case where no DHC servers exist (and haven't for a long time), but the admin decides it's time to enable DHC going forward. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 14:33:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCJp-0004jK-Vz; Fri, 20 May 2005 14:33:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCJn-0004hr-Pi; Fri, 20 May 2005 14:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21163; Fri, 20 May 2005 14:33:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCb9-0002X0-7O; Fri, 20 May 2005 14:51:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:33:42 -0400 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 j4KIXVe6025132; Fri, 20 May 2005 14:33:39 -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); Fri, 20 May 2005 14:33:19 -0400 Received: from 161.44.65.166 ([161.44.65.166]) 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 ; Fri, 20 May 2005 18:33:19 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 14:33:39 -0400 From: Ralph Droms To: ipv6@ietf.org, dhcwg@ietf.org In-Reply-To: <200505201753.j4KHreXo022341@rotala.raleigh.ibm.com> References: <200505201753.j4KHreXo022341@rotala.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 14:33:38 -0400 Message-Id: <1116614019.11164.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 18:33:19.0599 (UTC) FILETIME=[6537A7F0:01C55D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Subject: Re: meta thoughts on m/o bits 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 Well...DHCPv6 doesn't have any better mechanism for announcing availability of a server than does DHCPv4 (which is to say "none"). There has not been an identified need to push an announcement of DHCP server availability out to clients. Section 14 of RFC 3315 specifies the retransmission behavior for DHCP clients. When that behavior is interpreted for Solicit messages in section 17.1.2, the result is that the DHCP client continues to retransmit Solicit messages at low frequency (once every 2 minutes) forever. Therefore, the client will eventually contact the DHCP service when a server becomes available. - Ralph On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > This proposal looks better and easy to understand. However, > > if we just rely on timeout for concluding the unavailabiliy of DHCP server, > > how does the client re-invoke DHCP if the DHCP server is available later in > > time? I think we need one bit to inform the clients about the > > availabilty of DHCP > > services in the network. > > I would assume that DHC has mechanisms for discovering when DHC > servers come on line. I.e., the client just sits quietly in background. > > Sure, an RA bit could also signal the availability of a new server, > but I would first like to be convinced that the existing default DHC > mechanism isn't good enough for handling this case (better not to have > multiple ways of acheiving the same result). > > Thomas > > -------------------------------------------------------------------- > 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 May 20 14:43:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCTB-0000Tw-Os; Fri, 20 May 2005 14:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCTA-0000To-2B; Fri, 20 May 2005 14:43:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22827; Fri, 20 May 2005 14:43:34 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCkY-000300-Tm; Fri, 20 May 2005 15:01:36 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 14:54:16 -0400 X-IronPort-AV: i="3.93,124,1115006400"; d="scan'208"; a="50390264:sNHT28555176" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIgqnS021786; Fri, 20 May 2005 14:43:23 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:43:16 -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: Fri, 20 May 2005 14:43:14 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D66@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVdZArLm8ty52NqT/yepFCA7+YSOAABjlYQ From: "Bernie Volz \(volz\)" To: "Thomas Narten" , "JINMEI Tatuya / ????" X-OriginalArrivalTime: 20 May 2005 18:43:16.0483 (UTC) FILETIME=[C8FCED30:01C55D6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IPv6 WG Subject: RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Excellent points Thomas.=20 > > 5. what if the M flag is set but the host does not get any DHCPv6 > > Advertise in the initial exchange? Is it okay to fall=20 > back to the > > RFC3736 subset? Or is it even okay to run both full RFC3315 and > > the RFC3736 subset concurrently from the beginning? >=20 > Should be legal, but this is an unfortunate situation, since we're not > trying getting into how to deal with misconfigurations... >=20 Probably the correct behavior for a client is to fallback to 3736 but periodically try 3315. This is similar to what Microsoft clients have been doing for a long time ... If configured for DHCPv4, they'll attempt it for a while and if it fails, they autoconfigure an address. But, that doesn't mean they stop doing DHCPv4. In fact, the host continues to do so (albeit at a less aggressive rate). So, for a *full* featured DHCPv6 client, if it is told to run (either because of local policy or because M bit set), if SHOULD attempt stateful address configuration. After some number of attempts (perhaps only 1), it may attempt stateless (3736). If it gets stuff, great. However, in any case it should continue to send Solicit's periodically. Isn't it the case that for Stateless Autoconfiguration a host that never receives an RA for its RS will periodically send RSs? Though perhaps that's not correct because a router will periodically send RAs. Regardless of which way it works, the point is still the same ... There are periodic attempts to communicate and that should be no different for DHCPv6.=20 - Bernie -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 14:45:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCVH-0000pF-Qm; Fri, 20 May 2005 14:45:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCVG-0000p2-Ek; Fri, 20 May 2005 14:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23152; Fri, 20 May 2005 14:45:44 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCmg-00034v-4W; Fri, 20 May 2005 15:03:46 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:45:37 -0400 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 j4KIjFnQ022408; Fri, 20 May 2005 14:45:34 -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); Fri, 20 May 2005 14:45:17 -0400 Received: from 161.44.65.166 ([161.44.65.166]) 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 ; Fri, 20 May 2005 18:45:16 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 14:45:36 -0400 From: Ralph Droms To: dhcwg@ietf.org, ipv6@ietf.org In-Reply-To: <200505201833.j4KIX0Lr022951@rotala.raleigh.ibm.com> References: <200505201833.j4KIX0Lr022951@rotala.raleigh.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 14:45:36 -0400 Message-Id: <1116614736.11164.40.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 18:45:17.0028 (UTC) FILETIME=[10D6A240:01C55D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Subject: Re: meta thoughts on m/o bits 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 Comments in line... On Fri, 2005-05-20 at 14:33 -0400, Thomas Narten wrote: > > > => I'm curious about this, does DHCP broadcast its existence to > > > clients that never used it when it comes up? Seems a bit strange > > > to do that. I don't even know how it could speak to a client unsolicited. > > > > > > Yes, I do not think there is any message that has currently been defined > > in DHCP, that the servers broadcast without client solicitation. > > There are generally two ways to discover the existance of a server: > > - broadcast its existance (e.g., via a DHC broadcast or RA "DHC > server present" bit) There is no "DHCP broadcast", and changing the RA bit requires touching all the relevant routers. > - have clients periodically poll the server RFC 3315 currently specifies that clients poll (one message every two minutes) forever. > Each has different tradeoffs in terms of timeliness of discovering the > server vs. load on the network, etc. > > Those assuming a broadcast mechanism is needed may be making the > assumption that if an admin turns on a DHC server, it is a > _requirement_ that all nodes start using DHC effectively > _immediately_. > > It is not at all clear to me that this is a requirement. Which is why a broadcast mechanism in either DHCPv4 or DHCPv6. The operating environments for the two protocols are somewhat different; in general, if there is no DHCP server for IPv4 clients, those clients are simply unable to use the network, while if there is no DHCP server for IPv6 clients, those clients may be able to use SLAAC addresses. Either way, broadcasting the existence of a DHCP server is likely of value only in a very few, if any, cases. > I.e., it might be just fine to have all clients learn of DHC within > say 1-2 hours (if not longer), in which case background polling is > just fine. > > Remember, I don't think we're necessarily talking about the case where > a DHC server goes down. We're presumably talking about the case where > no DHC servers exist (and haven't for a long time), but the admin > decides it's time to enable DHC going forward. > > Thomas > > -------------------------------------------------------------------- > 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 May 20 14:49:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCYc-0001n0-QN; Fri, 20 May 2005 14:49:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCYb-0001mT-67; Fri, 20 May 2005 14:49:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23829; Fri, 20 May 2005 14:49:11 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCpz-0003Et-VR; Fri, 20 May 2005 15:07:13 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:bc95:2d64:c352:46ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 802B31521A; Sat, 21 May 2005 03:51:28 +0900 (JST) Date: Sat, 21 May 2005 03:50:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> References: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: meta thoughts on m/o bits 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 (cc'ing the dhcwg list) >>>>> On Fri, 20 May 2005 13:24:26 -0400, >>>>> Thomas Narten said: > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. As a meta thought, I cannot agree more. In fact, the points you showed are (almost) exactly what I wanted to make when we first discussed the M/O flags issue in the rfc2462bis work (but you seem to express the points much better than I did). We actually once considered this option, whereas we didn't see some of the relevant points we now know. See, for example, a very long thread a year ago: http://www1.ietf.org/mail-archive/web/ipv6/current/msg02285.html As you can see in the thread archive, there was a strong push-back against the idea of removing these flags (while some others supported the idea). Then we finally decided to not remove the flags after a heated discussion. So, I'm wondering whether we can now really convince those who opposed to the idea. One additional meta note: even if we now decide to remove the flags, it wouldn't affect rfc2462bis, since it does not mention the flags at all. However, the decision would require a non-trivial (while not so big) change to rfc2461bis, which contains these flags in the RA message format and a brief description of these flags. 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 May 20 14:49:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCZC-00024f-GR; Fri, 20 May 2005 14:49:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCZA-00024B-SQ; Fri, 20 May 2005 14:49:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24001; Fri, 20 May 2005 14:49:47 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCqZ-0003Hq-Nh; Fri, 20 May 2005 15:07:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:49:39 -0400 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 j4KInMeA029182; Fri, 20 May 2005 14:49:36 -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); Fri, 20 May 2005 14:49:21 -0400 Received: from 161.44.65.166 ([161.44.65.166]) 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 ; Fri, 20 May 2005 18:49:21 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 14:49:41 -0400 From: Ralph Droms To: dhcwg@ietf.org, ipv6@ietf.org In-Reply-To: <1116614736.11164.40.camel@localhost.localdomain> References: <200505201833.j4KIX0Lr022951@rotala.raleigh.ibm.com> <1116614736.11164.40.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 14:49:41 -0400 Message-Id: <1116614981.11164.42.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 18:49:21.0998 (UTC) FILETIME=[A2DA16E0:01C55D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: Re: [dhcwg] Re: meta thoughts on m/o bits 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 Small goof in previous message: > > Those assuming a broadcast mechanism is needed may be making the > > assumption that if an admin turns on a DHC server, it is a > > _requirement_ that all nodes start using DHC effectively > > _immediately_. > > > > It is not at all clear to me that this is a requirement. > > Which is why a broadcast mechanism in either DHCPv4 or DHCPv6. The ^is not defined > operating environments for the two protocols are somewhat different; in > general, if there is no DHCP server for IPv4 clients, those clients are > simply unable to use the network, while if there is no DHCP server for > IPv6 clients, those clients may be able to use SLAAC addresses. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 14:51:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCav-0002fI-GV; Fri, 20 May 2005 14:51:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCan-0002db-6j; Fri, 20 May 2005 14:51:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24228; Fri, 20 May 2005 14:51:27 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCsC-0003LC-01; Fri, 20 May 2005 15:09:29 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 14:51:17 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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, 20 May 2005 14:50:15 -0400 Message-ID: Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdatgOTN4uDSjQSKydhtn70c2XFAAAVovw From: "Soliman, Hesham" To: "Ralph Droms" , , X-OriginalArrivalTime: 20 May 2005 18:51:17.0712 (UTC) FILETIME=[E7D2A500:01C55D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: meta thoughts on m/o bits 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 some scenarios there is a danger in the following approach: - hosts boots - looks for DHCP server, doesn't find one - Keeps looking every couple of minutes This leads to inefficient use of power and network resources=20 in some wireless devices. A more efficient way to do things is=20 to indicate in the RA whether the host should even try to find a DHCP server. I find the current description in 2461/2bis sufficient, dynamic and provides enough granularity to allow hosts to look for what they need (i.e. addresses or "other" config).=20 As a side note, we must not force DHCP to be a default address=20 configuration mechanism in IPv6. Stateless address config actually provides a very useful and timely way of configuring addresses=20 for mobile nodes. Hesham > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > Behalf Of > Ralph Droms > Sent: Friday, May 20, 2005 2:34 PM > To: ipv6@ietf.org; dhcwg@ietf.org > Subject: Re: meta thoughts on m/o bits >=20 >=20 > Well...DHCPv6 doesn't have any better mechanism for announcing > availability of a server than does DHCPv4 (which is to say "none"). > There has not been an identified need to push an announcement of DHCP > server availability out to clients. >=20 > Section 14 of RFC 3315 specifies the retransmission behavior for DHCP > clients. When that behavior is interpreted for Solicit messages in > section 17.1.2, the result is that the DHCP client continues to > retransmit Solicit messages at low frequency (once every 2 minutes) > forever. Therefore, the client will eventually contact the=20 > DHCP service > when a server becomes available. >=20 > - Ralph >=20 > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > This proposal looks better and easy to understand. However, > > > if we just rely on timeout for concluding the=20 > unavailabiliy of DHCP server, > > > how does the client re-invoke DHCP if the DHCP server is=20 > available later in=20 > > > time? I think we need one bit to inform the clients about the > > > availabilty of DHCP > > > services in the network. > >=20 > > I would assume that DHC has mechanisms for discovering when DHC > > servers come on line. I.e., the client just sits quietly=20 > in background. > >=20 > > Sure, an RA bit could also signal the availability of a new server, > > but I would first like to be convinced that the existing=20 > default DHC > > mechanism isn't good enough for handling this case (better=20 > not to have > > multiple ways of acheiving the same result). > >=20 > > Thomas > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 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 -------------------------------------------------------------------- =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 May 20 14:52:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCc5-000380-5X; Fri, 20 May 2005 14:52:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCc4-00037g-49; Fri, 20 May 2005 14:52:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24407; Fri, 20 May 2005 14:52:46 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZCtT-0003PC-LH; Fri, 20 May 2005 15:10:48 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 14:52:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KIqFnW024378; Fri, 20 May 2005 14:52:35 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 14:52:26 -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: Fri, 20 May 2005 14:52:25 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D6A@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] FWD: meta thoughts on m/o bits Thread-Index: AcVdYkVa1uCJX/WFR+aXQsg546CRDAACfj4A From: "Bernie Volz \(volz\)" To: "Thomas Narten" , , X-OriginalArrivalTime: 20 May 2005 18:52:26.0195 (UTC) FILETIME=[10A45230:01C55D6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: [dhcwg] FWD: meta thoughts on m/o bits 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 has my full support ... I kind of like the idea of one bit to say "run-DHCP if you otherwise wouldn't" but would leave the meaning as simple as that. Those hosts that run DHCP always (because that is how they are 'configured'), would do so. Note that if this bit is set, it means run FULL 3315 if you're able to and 3736 if you're not. Of course, if there's no DHCP client ... The client won't run either. That way, networks were bandwidth is a expensive or primarily mandate NOT using DHCP (or just stateless DHCP), COULD do so. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Thomas Narten > Sent: Friday, May 20, 2005 1:33 PM > To: dhcwg@ietf.org > Subject: [dhcwg] FWD: meta thoughts on m/o bits >=20 > Forgot to cc the dhc group on this. >=20 > ------- Forwarded Message >=20 > From: Thomas Narten > To: ipv6@ietf.org > Date: Fri, 20 May 2005 13:24:26 -0400 > Subject: meta thoughts on m/o bits >=20 > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... >=20 > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. >=20 > In an ideal world, there would be exactly one way for a client to > invoke DHC. That is, it would use the same message exchange to get > "addresses" as it did for "non-address configuration". In such a > world, there would be no need for the M/O bits, since the client would > do the same thing if either one of them were set. >=20 > Unfortunately, we are not quite there, since DHC actually has HCB & > ICB message exchanges (using Ralph's terminology). Thus, there are > scenarios where invoking ICB is preferable over HCB. (Aside note: here > is another example where having two ways to do similar things, results > in undesirable complexity). Currently, we sort of need the M/O bits so > a client can know which variant of DHC to invoke. But, we now also > allow for the possibility of "silly states", i.e., states that aren't > supposed to happen, but can, e.g., through misconfiguration. Having > the M bit set but no addresses available is one such example. >=20 > Ralph has already indicated that with some small changes to the DHC > spec, we might be able to fix the DHC issue so that there is one way > to invoke DHC that does the right thing in all combinations of > addresses and/or other configuration information being available via > DHC. >=20 > If we had that, we wouldn't need two RA bits anymore. At most, a > single "there is stuff to obtain via DHC" bit would suffice. >=20 > Indeed, one could go further and say "just always invoke DHC", and > don't even bother with an RA bit saying DHC is available. That has the > nice property of being simple to implement and you don't have silly > states where the RA bit(s) are configured incorrectly, etc. >=20 > The only advantage I can see right off to having at least 1 RA bit is > to tell the client "there is no DHC server running, so don't even > bother". This would be a performance optimization to allow one to > avoid needing to invoke DHC and have it timeout -- before concluding > that there are no DHC servers. Is this a significant optimization? > Hard to say. >=20 > What I would like to suggest: followup on the above proposed DHC > changes and see if we can actually "fix" DHC to simplify what the > client has to do to invoke it. And if that works, do away with one or > both of the RA bits. >=20 > Remember, simplicity is Good! >=20 > Thomas >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 15:06:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCor-0008BN-Lg; Fri, 20 May 2005 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCop-0008Am-O9; Fri, 20 May 2005 15:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26191; Fri, 20 May 2005 15:05:58 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZD6D-0003rE-IK; Fri, 20 May 2005 15:24:00 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 15:05:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KJ5VnW028313; Fri, 20 May 2005 15:05:46 -0400 (EDT) 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); Fri, 20 May 2005 15:05:43 -0400 Received: from 161.44.65.166 ([161.44.65.166]) 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 ; Fri, 20 May 2005 19:05:43 +0000 Received: from localhost.localdomain by email.cisco.com; 20 May 2005 15:06:03 -0400 From: Ralph Droms To: "Soliman, Hesham" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 20 May 2005 15:06:03 -0400 Message-Id: <1116615963.11164.60.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 20 May 2005 19:05:43.0856 (UTC) FILETIME=[EC15BB00:01C55D6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: meta thoughts on m/o bits 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 No one is suggesting DHCP is the "default address configuration mechanism". Let's *please* not go down that discussion path... More comments in line. On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > In some scenarios there is a danger in the following approach: > - hosts boots > - looks for DHCP server, doesn't find one > - Keeps looking every couple of minutes A client is free to use some other timeout (2 hours instead of 2 minutes?) if it chooses. See sections 5, 14 and 17.1.2 of RFC 3315. I imagine standards bodies for specific environments (3GPP2?) might well mandate different retransmit timeouts, for example, to conserve bandwidth or power. > This leads to inefficient use of power and network resources > in some wireless devices. A more efficient way to do things is > to indicate in the RA whether the host should even try to find > a DHCP server. I find the current description in 2461/2bis > sufficient, dynamic and provides enough granularity to allow > hosts to look for what they need (i.e. addresses or "other" config). Yes, a bit indicating whether to expect a DHCP service at all might be useful ... although I, as an implementor, might be tempted to try the DHCP service anyway in certain circumstances; suppose there are no advertised prefixes from which to assign SLAAC addresses? > As a side note, we must not force DHCP to be a default address > configuration mechanism in IPv6. Stateless address config actually > provides a very useful and timely way of configuring addresses > for mobile nodes. > > Hesham > > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On > > Behalf Of > > Ralph Droms > > Sent: Friday, May 20, 2005 2:34 PM > > To: ipv6@ietf.org; dhcwg@ietf.org > > Subject: Re: meta thoughts on m/o bits > > > > > > Well...DHCPv6 doesn't have any better mechanism for announcing > > availability of a server than does DHCPv4 (which is to say "none"). > > There has not been an identified need to push an announcement of DHCP > > server availability out to clients. > > > > Section 14 of RFC 3315 specifies the retransmission behavior for DHCP > > clients. When that behavior is interpreted for Solicit messages in > > section 17.1.2, the result is that the DHCP client continues to > > retransmit Solicit messages at low frequency (once every 2 minutes) > > forever. Therefore, the client will eventually contact the > > DHCP service > > when a server becomes available. > > > > - Ralph > > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > This proposal looks better and easy to understand. However, > > > > if we just rely on timeout for concluding the > > unavailabiliy of DHCP server, > > > > how does the client re-invoke DHCP if the DHCP server is > > available later in > > > > time? I think we need one bit to inform the clients about the > > > > availabilty of DHCP > > > > services in the network. > > > > > > I would assume that DHC has mechanisms for discovering when DHC > > > servers come on line. I.e., the client just sits quietly > > in background. > > > > > > Sure, an RA bit could also signal the availability of a new server, > > > but I would first like to be convinced that the existing > > default DHC > > > mechanism isn't good enough for handling this case (better > > not to have > > > multiple ways of acheiving the same result). > > > > > > Thomas > > > > > > > > -------------------------------------------------------------------- > > > 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 > -------------------------------------------------------------------- > > =========================================================== > 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 May 20 15:07:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCq5-0008Qz-MI; Fri, 20 May 2005 15:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCq4-0008QX-6f for ipv6@megatron.ietf.org; Fri, 20 May 2005 15:07:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26382 for ; Fri, 20 May 2005 15:07:14 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZD7T-0003tf-5J for ipv6@ietf.org; Fri, 20 May 2005 15:25:16 -0400 Received: by rproxy.gmail.com with SMTP id a41so536873rng for ; Fri, 20 May 2005 12:07:13 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f/0TuTrHZ6CNk5jQhzlDJkwTy6vKd3ex9dRQUsTjR7VXygM5VZmSkllPt0U7UX39EjRS2xEsmK4NrOHYyY748GtL+ukbDDYghx4VSsZ+lP/ukBqPQcyFXJdH/I2/+AsNPqj8InHinAdicnKQad1CuHLEWmSfhKvQiDg2AkK4fOw= Received: by 10.38.9.14 with SMTP id 14mr830458rni; Fri, 20 May 2005 12:07:13 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Fri, 20 May 2005 12:07:13 -0700 (PDT) Message-ID: <10e14db205052012077ee1fe99@mail.gmail.com> Date: Sat, 21 May 2005 00:37:13 +0530 From: Syam Madanapalli To: ipv6@ietf.org, dhcwg@ietf.org In-Reply-To: <1116614019.11164.34.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200505201753.j4KHreXo022341@rotala.raleigh.ibm.com> <1116614019.11164.34.camel@localhost.localdomain> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: [dhcwg] Re: meta thoughts on m/o bits X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Syam Madanapalli 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 5/21/05, Ralph Droms wrote: > Well...DHCPv6 doesn't have any better mechanism for announcing > availability of a server than does DHCPv4 (which is to say "none"). > There has not been an identified need to push an announcement of DHCP > server availability out to clients. > > Section 14 of RFC 3315 specifies the retransmission behavior for DHCP > clients. When that behavior is interpreted for Solicit messages in > section 17.1.2, the result is that the DHCP client continues to > retransmit Solicit messages at low frequency (once every 2 minutes) > forever. Therefore, the client will eventually contact the DHCP service > when a server becomes available. This may not be efficient for wireless networks where power and bandwidth are crucial. > > - Ralph > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > This proposal looks better and easy to understand. However, > > > if we just rely on timeout for concluding the unavailabiliy of DHCP s= erver, > > > how does the client re-invoke DHCP if the DHCP server is available la= ter in > > > time? I think we need one bit to inform the clients about the > > > availabilty of DHCP > > > services in the network. > > > > I would assume that DHC has mechanisms for discovering when DHC > > servers come on line. I.e., the client just sits quietly in background. > > > > Sure, an RA bit could also signal the availability of a new server, > > but I would first like to be convinced that the existing default DHC > > mechanism isn't good enough for handling this case (better not to have > > multiple ways of acheiving the same result). > > > > Thomas > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 15:16:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCyf-0002mV-BL; Fri, 20 May 2005 15:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZCye-0002lt-1y; Fri, 20 May 2005 15:16:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28176; Fri, 20 May 2005 15:16:06 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDG4-0004Gc-3w; Fri, 20 May 2005 15:34:08 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 15:15:58 -0400 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: Fri, 20 May 2005 15:14:56 -0400 Message-ID: Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdbssH2+mYkiCqTVyvr9/puMHYcwAAPLbw From: "Soliman, Hesham" To: "Ralph Droms" X-OriginalArrivalTime: 20 May 2005 19:15:58.0639 (UTC) FILETIME=[5A862BF0:01C55D70] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: meta thoughts on m/o bits 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 > No one is suggesting DHCP is the "default address configuration > mechanism". Let's *please* not go down that discussion path... =3D> some parts of the discussion were hinting at that, that's=20 why I said "side note". I'm glad you're not suggesting that. >=20 > More comments in line. >=20 > On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > > In some scenarios there is a danger in the following approach: > > - hosts boots > > - looks for DHCP server, doesn't find one > > - Keeps looking every couple of minutes >=20 > A client is free to use some other timeout (2 hours instead of 2 > minutes?) if it chooses. See sections 5, 14 and 17.1.2 of=20 > RFC 3315. I > imagine standards bodies for specific environments (3GPP2?)=20 > might well > mandate different retransmit timeouts, for example, to conserve > bandwidth or power. =3D> It's unrealistic to assume that. An SDO might suggest that but how does an implementation know it's in a 3GPP/2 or some other=20 wireless network, or even ethernet? An implementation might just=20 see a PPP driver or an ethernet driver. That says nothing about=20 the underlying technology. >=20 > > This leads to inefficient use of power and network resources=20 > > in some wireless devices. A more efficient way to do things is=20 > > to indicate in the RA whether the host should even try to find > > a DHCP server. I find the current description in 2461/2bis > > sufficient, dynamic and provides enough granularity to allow > > hosts to look for what they need (i.e. addresses or=20 > "other" config). >=20 > Yes, a bit indicating whether to expect a DHCP service at=20 > all might be > useful ... although I, as an implementor, might be tempted to try the > DHCP service anyway in certain circumstances; suppose there are no > advertised prefixes from which to assign SLAAC addresses? =3D> You can try, but my concern is about how often you're going to try. If there are bits that say whether you should try or not and those=20 bits are not set (i.e. no DHCP server in the network), why would you = try? Hesham >=20 > > As a side note, we must not force DHCP to be a default address=20 > > configuration mechanism in IPv6. Stateless address config actually > > provides a very useful and timely way of configuring addresses=20 > > for mobile nodes. > >=20 > > Hesham > >=20 > >=20 > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > > > Behalf Of > > > Ralph Droms > > > Sent: Friday, May 20, 2005 2:34 PM > > > To: ipv6@ietf.org; dhcwg@ietf.org > > > Subject: Re: meta thoughts on m/o bits > > >=20 > > >=20 > > > Well...DHCPv6 doesn't have any better mechanism for announcing > > > availability of a server than does DHCPv4 (which is to=20 > say "none"). > > > There has not been an identified need to push an=20 > announcement of DHCP > > > server availability out to clients. > > >=20 > > > Section 14 of RFC 3315 specifies the retransmission=20 > behavior for DHCP > > > clients. When that behavior is interpreted for Solicit=20 > messages in > > > section 17.1.2, the result is that the DHCP client continues to > > > retransmit Solicit messages at low frequency (once=20 > every 2 minutes) > > > forever. Therefore, the client will eventually contact the=20 > > > DHCP service > > > when a server becomes available. > > >=20 > > > - Ralph > > >=20 > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > > This proposal looks better and easy to understand. However, > > > > > if we just rely on timeout for concluding the=20 > > > unavailabiliy of DHCP server, > > > > > how does the client re-invoke DHCP if the DHCP server is=20 > > > available later in=20 > > > > > time? I think we need one bit to inform the clients=20 > about the > > > > > availabilty of DHCP > > > > > services in the network. > > > >=20 > > > > I would assume that DHC has mechanisms for=20 > discovering when DHC > > > > servers come on line. I.e., the client just sits quietly=20 > > > in background. > > > >=20 > > > > Sure, an RA bit could also signal the availability of=20 > a new server, > > > > but I would first like to be convinced that the existing=20 > > > default DHC > > > > mechanism isn't good enough for handling this case (better=20 > > > not to have > > > > multiple ways of acheiving the same result). > > > >=20 > > > > Thomas > > > >=20 > > > >=20 > > >=20 > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests:=20 > > https://www1.ietf.org/mailman/listinfo/ipv6 > > >=20 > -------------------------------------------------------------------- > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 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 May 20 15:26:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZD8m-0006N4-JP; Fri, 20 May 2005 15:26:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZD8l-0006Mt-Gq; Fri, 20 May 2005 15:26:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29446; Fri, 20 May 2005 15:26:33 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDQA-0004YK-9Y; Fri, 20 May 2005 15:44:35 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 May 2005 15:37:14 -0400 X-IronPort-AV: i="3.93,124,1115006400"; d="scan'208"; a="50398108:sNHT33679436" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4KJPbns003985; Fri, 20 May 2005 15:26:20 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 15:26:17 -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: Fri, 20 May 2005 15:26:16 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3D87@xmb-rtp-20a.amer.cisco.com> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdbssH2+mYkiCqTVyvr9/puMHYcwAAPLbwAABbcEA= From: "Bernie Volz \(volz\)" To: "Soliman, Hesham" , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 20 May 2005 19:26:17.0184 (UTC) FILETIME=[CB34A600:01C55D71] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: meta thoughts on m/o bits 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 Hesham: > =3D> You can try, but my concern is about how often you're going to = try. > If there are bits that say whether you should try or not and those=20 > bits are not set (i.e. no DHCP server in the network), why=20 > would you try? =20 This means that the wiresless operators will get more revenue from Ralph! If the wireless operator isn't using DHCP (or only using stateless), there's no reason they can't charge for that (stateful) traffic. This is the reason why having one (or two) bits in the RA to indicate whether DHCP should be run are useful. But, those bits are advisory only. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Soliman, Hesham > Sent: Friday, May 20, 2005 3:15 PM > To: Ralph Droms (rdroms) > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: meta thoughts on m/o bits >=20 >=20 >=20 > > No one is suggesting DHCP is the "default address configuration > > mechanism". Let's *please* not go down that discussion path... >=20 > =3D> some parts of the discussion were hinting at that, that's=20 > why I said "side note". I'm glad you're not suggesting that. >=20 > >=20 > > More comments in line. > >=20 > > On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > > > In some scenarios there is a danger in the following approach: > > > - hosts boots > > > - looks for DHCP server, doesn't find one > > > - Keeps looking every couple of minutes > >=20 > > A client is free to use some other timeout (2 hours instead of 2 > > minutes?) if it chooses. See sections 5, 14 and 17.1.2 of=20 > > RFC 3315. I > > imagine standards bodies for specific environments (3GPP2?)=20 > > might well > > mandate different retransmit timeouts, for example, to conserve > > bandwidth or power. >=20 > =3D> It's unrealistic to assume that. An SDO might suggest that but > how does an implementation know it's in a 3GPP/2 or some other=20 > wireless network, or even ethernet? An implementation might just=20 > see a PPP driver or an ethernet driver. That says nothing about=20 > the underlying technology. >=20 > >=20 > > > This leads to inefficient use of power and network resources=20 > > > in some wireless devices. A more efficient way to do things is=20 > > > to indicate in the RA whether the host should even try to find > > > a DHCP server. I find the current description in 2461/2bis > > > sufficient, dynamic and provides enough granularity to allow > > > hosts to look for what they need (i.e. addresses or=20 > > "other" config). > >=20 > > Yes, a bit indicating whether to expect a DHCP service at=20 > > all might be > > useful ... although I, as an implementor, might be tempted=20 > to try the > > DHCP service anyway in certain circumstances; suppose there are no > > advertised prefixes from which to assign SLAAC addresses? >=20 > =3D> You can try, but my concern is about how often you're going to = try. > If there are bits that say whether you should try or not and those=20 > bits are not set (i.e. no DHCP server in the network), why=20 > would you try? >=20 > Hesham >=20 > >=20 > > > As a side note, we must not force DHCP to be a default address=20 > > > configuration mechanism in IPv6. Stateless address=20 > config actually > > > provides a very useful and timely way of configuring addresses=20 > > > for mobile nodes. > > >=20 > > > Hesham > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > > > > Behalf Of > > > > Ralph Droms > > > > Sent: Friday, May 20, 2005 2:34 PM > > > > To: ipv6@ietf.org; dhcwg@ietf.org > > > > Subject: Re: meta thoughts on m/o bits > > > >=20 > > > >=20 > > > > Well...DHCPv6 doesn't have any better mechanism for announcing > > > > availability of a server than does DHCPv4 (which is to=20 > > say "none"). > > > > There has not been an identified need to push an=20 > > announcement of DHCP > > > > server availability out to clients. > > > >=20 > > > > Section 14 of RFC 3315 specifies the retransmission=20 > > behavior for DHCP > > > > clients. When that behavior is interpreted for Solicit=20 > > messages in > > > > section 17.1.2, the result is that the DHCP client=20 > continues to > > > > retransmit Solicit messages at low frequency (once=20 > > every 2 minutes) > > > > forever. Therefore, the client will eventually contact the=20 > > > > DHCP service > > > > when a server becomes available. > > > >=20 > > > > - Ralph > > > >=20 > > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > > > This proposal looks better and easy to=20 > understand. However, > > > > > > if we just rely on timeout for concluding the=20 > > > > unavailabiliy of DHCP server, > > > > > > how does the client re-invoke DHCP if the DHCP server is=20 > > > > available later in=20 > > > > > > time? I think we need one bit to inform the clients=20 > > about the > > > > > > availabilty of DHCP > > > > > > services in the network. > > > > >=20 > > > > > I would assume that DHC has mechanisms for=20 > > discovering when DHC > > > > > servers come on line. I.e., the client just sits quietly=20 > > > > in background. > > > > >=20 > > > > > Sure, an RA bit could also signal the availability of=20 > > a new server, > > > > > but I would first like to be convinced that the existing=20 > > > > default DHC > > > > > mechanism isn't good enough for handling this case (better=20 > > > > not to have > > > > > multiple ways of acheiving the same result). > > > > >=20 > > > > > Thomas > > > > >=20 > > > > >=20 > > > >=20 > >=20 > -------------------------------------------------------------------- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests:=20 > > > https://www1.ietf.org/mailman/listinfo/ipv6 > > > >=20 > >=20 > -------------------------------------------------------------------- > > >=20 > > >=20 > >=20 > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests:=20 > 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=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 > -------------------------------------------------------------------- > 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 Fri May 20 15:31:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDDF-0006rH-7b; Fri, 20 May 2005 15:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDDB-0006pa-TA; Fri, 20 May 2005 15:31:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29812; Fri, 20 May 2005 15:31:08 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDUa-0004f0-BL; Fri, 20 May 2005 15:49:10 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:bc95:2d64:c352:46ff]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5403A1521D; Sat, 21 May 2005 04:33:22 +0900 (JST) Date: Sat, 21 May 2005 04:31:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dhcwg@ietf.org, IPv6 WG , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Fri, 20 May 2005 13:47:25 -0400, >>>>> Thomas Narten said: > That is, vendors always implement additional knobs/whistles as they > see fit. The IETF doesn't need to account for all of those. > What we our specs do need to support is not disallowing behavior that > it might make sense to allow for, and that doesn't negatively impact > interoperability and such. > The above should be perfectly consistent with our existing specs. Do > you (or others) feel otherwise? I.e., is the above not allowed by our > specs? (Perhaps it's not wise to continue this thread while we are in the separate "meta" thread, but) I believe we've basically agreed on each technical point (e.g., whether a host can perform DHCPv6 based on its decision/policy even if the corresponding M/O flag is off; the answer is "it can"). The real point in this thread is, at least to me, as follows: It's the fact that people have actually been confused about these points. We now know the answers to the questions, but I'm quite sure new implementors will ask the same questions in the future, since most of the background rationale is implicit, e.g., "this is valid since no specification explicitly prohibits it", and we'll continue answering the questions by saying "yes, it's valid because no specification explicitly prohibits it". I don't know if such confusion is just usual in the IETF specifications or there is something special for the M/O flags and DHCPv6 case, due to, for example, partly overwrapping functionality of "Host Configuration Behavior (full RFC3315)" and "Configuration Information Behavior (RFC3736 subset)" or other complexity you mentioned in the other thread. I personally think this is the latter case, and it makes sense to clarify these points explicitly in order to help future implementors (and ourselves by avoiding seeing/answering the same questions again and again). If I don't misunderstand him, Ralph also seems to think some clarification is useful. On the other hand, you and some other guys seem to regard this as a usual case which does not require explicit clarification. If this group is the majority, I won't fight against it; at least I now know the answers to the questions, so (hopefully) I won't be confused any more:-) 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 May 20 15:36:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDI1-0007tH-LR; Fri, 20 May 2005 15:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDHz-0007st-FC for ipv6@megatron.ietf.org; Fri, 20 May 2005 15:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00488 for ; Fri, 20 May 2005 15:36:05 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDZO-0004oN-K5 for ipv6@ietf.org; Fri, 20 May 2005 15:54:08 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KJZsrj018488 for ; Fri, 20 May 2005 15:35:54 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KJZsi4151878 for ; Fri, 20 May 2005 15:35:54 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KJZsAQ031522 for ; Fri, 20 May 2005 15:35:54 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KJZstO031512; Fri, 20 May 2005 15:35:54 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KJZrRJ023328; Fri, 20 May 2005 15:35:53 -0400 Message-Id: <200505201935.j4KJZrRJ023328@rotala.raleigh.ibm.com> To: Bob Hinden In-Reply-To: Message from bob.hinden@nokia.com of "Wed, 18 May 2005 14:46:27 PDT." <6.2.1.2.2.20050518143251.02f60f90@mailhost.iprg.nokia.com> Date: Fri, 20 May 2005 15:35:53 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipv6@ietf.org Subject: Re: Proposed changes to IPv6 Address Architecture draft 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 Bob, The changes look good to me. One thing I noticed while reading this text (and this issue actually was in previous versions): > +-+-+-+-+ > flgs is a set of 4 flags: |0|R|P|T| > +-+-+-+-+ > The high-order flag is reserved, and must be initialized to 0. Because the high-order flag is reserved, its contents should be ignored by all implementations. So "must be initialized to 0" is perhaps better just dropped, to prevent an implementer from thinking they need to (somehow) verify/check this. Maybe change to: The high-order flag is reserved, and its value should be ignored on receipt (other than being considered part of the address when performing address comparisons). (Maybe the last part is too long/complicated/obvious, in which case just dropping it might be better.) I'm also fine with not adding any additional text to the IANA considerations regarding the unicast/multicast instructions. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 15:38:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDJx-0008RY-BP; Fri, 20 May 2005 15:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZDJv-0008RC-BO; Fri, 20 May 2005 15:38:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00860; Fri, 20 May 2005 15:38:05 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZDbK-0004uj-EG; Fri, 20 May 2005 15:56:07 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 15:37:55 -0400 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: Fri, 20 May 2005 15:36:53 -0400 Message-ID: Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVdbssH2+mYkiCqTVyvr9/puMHYcwAAPLbwAABbcEAAAHq+AA== From: "Soliman, Hesham" To: "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 20 May 2005 19:37:55.0616 (UTC) FILETIME=[6B80EA00:01C55D73] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: meta thoughts on m/o bits 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 Bernie,=20 > > =3D> You can try, but my concern is about how often you're=20 > going to try. > > If there are bits that say whether you should try or not and those=20 > > bits are not set (i.e. no DHCP server in the network), why=20 > > would you try? > =20 > This means that the wiresless operators will get more revenue from > Ralph! >=20 > If the wireless operator isn't using DHCP (or only using stateless), > there's no reason they can't charge for that (stateful) traffic. =3D> :) I don't want them to charge users for Ralph's implementation :) But seriously, charging is one thing, inefficient use of power is=20 another serious problem which can actually reduce revenue because a device doesn't go dormant long enough and runs out of battery=20 instead of using that battery power for what the user actually wants to do. Hesham >=20 > This is the reason why having one (or two) bits in the RA to indicate > whether DHCP should be run are useful. But, those bits are advisory > only. >=20 > - Bernie >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > > Behalf Of Soliman, Hesham > > Sent: Friday, May 20, 2005 3:15 PM > > To: Ralph Droms (rdroms) > > Cc: dhcwg@ietf.org; ipv6@ietf.org > > Subject: RE: meta thoughts on m/o bits > >=20 > >=20 > >=20 > > > No one is suggesting DHCP is the "default address configuration > > > mechanism". Let's *please* not go down that discussion path... > >=20 > > =3D> some parts of the discussion were hinting at that, that's=20 > > why I said "side note". I'm glad you're not suggesting that. > >=20 > > >=20 > > > More comments in line. > > >=20 > > > On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > > > > In some scenarios there is a danger in the following approach: > > > > - hosts boots > > > > - looks for DHCP server, doesn't find one > > > > - Keeps looking every couple of minutes > > >=20 > > > A client is free to use some other timeout (2 hours instead of 2 > > > minutes?) if it chooses. See sections 5, 14 and 17.1.2 of=20 > > > RFC 3315. I > > > imagine standards bodies for specific environments (3GPP2?)=20 > > > might well > > > mandate different retransmit timeouts, for example, to conserve > > > bandwidth or power. > >=20 > > =3D> It's unrealistic to assume that. An SDO might suggest that but > > how does an implementation know it's in a 3GPP/2 or some other=20 > > wireless network, or even ethernet? An implementation might just=20 > > see a PPP driver or an ethernet driver. That says nothing about=20 > > the underlying technology. > >=20 > > >=20 > > > > This leads to inefficient use of power and network resources=20 > > > > in some wireless devices. A more efficient way to do=20 > things is=20 > > > > to indicate in the RA whether the host should even try to find > > > > a DHCP server. I find the current description in 2461/2bis > > > > sufficient, dynamic and provides enough granularity to allow > > > > hosts to look for what they need (i.e. addresses or=20 > > > "other" config). > > >=20 > > > Yes, a bit indicating whether to expect a DHCP service at=20 > > > all might be > > > useful ... although I, as an implementor, might be tempted=20 > > to try the > > > DHCP service anyway in certain circumstances; suppose=20 > there are no > > > advertised prefixes from which to assign SLAAC addresses? > >=20 > > =3D> You can try, but my concern is about how often you're=20 > going to try. > > If there are bits that say whether you should try or not and those=20 > > bits are not set (i.e. no DHCP server in the network), why=20 > > would you try? > >=20 > > Hesham > >=20 > > >=20 > > > > As a side note, we must not force DHCP to be a=20 > default address=20 > > > > configuration mechanism in IPv6. Stateless address=20 > > config actually > > > > provides a very useful and timely way of configuring=20 > addresses=20 > > > > for mobile nodes. > > > >=20 > > > > Hesham > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: ipv6-bounces@ietf.org=20 > [mailto:ipv6-bounces@ietf.org]On=20 > > > > > Behalf Of > > > > > Ralph Droms > > > > > Sent: Friday, May 20, 2005 2:34 PM > > > > > To: ipv6@ietf.org; dhcwg@ietf.org > > > > > Subject: Re: meta thoughts on m/o bits > > > > >=20 > > > > >=20 > > > > > Well...DHCPv6 doesn't have any better mechanism=20 > for announcing > > > > > availability of a server than does DHCPv4 (which is to=20 > > > say "none"). > > > > > There has not been an identified need to push an=20 > > > announcement of DHCP > > > > > server availability out to clients. > > > > >=20 > > > > > Section 14 of RFC 3315 specifies the retransmission=20 > > > behavior for DHCP > > > > > clients. When that behavior is interpreted for Solicit=20 > > > messages in > > > > > section 17.1.2, the result is that the DHCP client=20 > > continues to > > > > > retransmit Solicit messages at low frequency (once=20 > > > every 2 minutes) > > > > > forever. Therefore, the client will eventually=20 > contact the=20 > > > > > DHCP service > > > > > when a server becomes available. > > > > >=20 > > > > > - Ralph > > > > >=20 > > > > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > > > > > This proposal looks better and easy to=20 > > understand. However, > > > > > > > if we just rely on timeout for concluding the=20 > > > > > unavailabiliy of DHCP server, > > > > > > > how does the client re-invoke DHCP if the DHCP=20 > server is=20 > > > > > available later in=20 > > > > > > > time? I think we need one bit to inform the clients=20 > > > about the > > > > > > > availabilty of DHCP > > > > > > > services in the network. > > > > > >=20 > > > > > > I would assume that DHC has mechanisms for=20 > > > discovering when DHC > > > > > > servers come on line. I.e., the client just sits quietly=20 > > > > > in background. > > > > > >=20 > > > > > > Sure, an RA bit could also signal the availability of=20 > > > a new server, > > > > > > but I would first like to be convinced that the existing=20 > > > > > default DHC > > > > > > mechanism isn't good enough for handling this=20 > case (better=20 > > > > > not to have > > > > > > multiple ways of acheiving the same result). > > > > > >=20 > > > > > > Thomas > > > > > >=20 > > > > > >=20 > > > > >=20 > > >=20 > >=20 > -------------------------------------------------------------------- > > > > > > IETF IPv6 working group mailing list > > > > > > ipv6@ietf.org > > > > > > Administrative Requests:=20 > > > > https://www1.ietf.org/mailman/listinfo/ipv6 > > > > >=20 > > >=20 > >=20 > -------------------------------------------------------------------- > > > >=20 > > > >=20 > > >=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 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 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 Fri May 20 16:30:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZE8S-0001AD-V5; Fri, 20 May 2005 16:30:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZE8R-00019z-EN for ipv6@megatron.ietf.org; Fri, 20 May 2005 16:30:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11545 for ; Fri, 20 May 2005 16:30:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZEPq-0000CX-PX for ipv6@ietf.org; Fri, 20 May 2005 16:48:20 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4KJwps26577; Fri, 20 May 2005 12:58:51 -0700 X-mProtect: <200505201958> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd4sDIiN; Fri, 20 May 2005 12:58:49 PDT Message-Id: <6.2.1.2.2.20050520131416.02c63f80@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 20 May 2005 13:29:51 -0700 To: Thomas Narten From: Bob Hinden In-Reply-To: <200505201935.j4KJZrRJ023328@rotala.raleigh.ibm.com> References: <200505201935.j4KJZrRJ023328@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ipv6@ietf.org Subject: Re: Proposed changes to IPv6 Address Architecture draft 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 Thomas, At 12:35 PM 05/20/2005, Thomas Narten wrote: >Bob, > >The changes look good to me. Thanks! >One thing I noticed while reading this text (and this issue actually >was in previous versions): > > > +-+-+-+-+ > > flgs is a set of 4 flags: |0|R|P|T| > > +-+-+-+-+ > > > The high-order flag is reserved, and must be initialized to 0. > >Because the high-order flag is reserved, its contents should be >ignored by all implementations. So "must be initialized to 0" is >perhaps better just dropped, to prevent an implementer from thinking >they need to (somehow) verify/check this. Maybe change to: > > The high-order flag is reserved, and its value should be > ignored on receipt (other than being considered part of the > address when performing address comparisons). > >(Maybe the last part is too long/complicated/obvious, in which case >just dropping it might be better.) I agree it gets complicated trying to spell this out because implementations don't set the flags in a multicast address like they might dynamically set a flag in a protocol header. However, I think we do want to do something to insure that it is zero so as to avoid ending up with two different multicast address for the same thing. How about if it just says: The high-order flag is reserved and must be zero. This avoids the idea that an implementation might have to initialize it dynamically. >I'm also fine with not adding any additional text to the IANA >considerations regarding the unicast/multicast instructions. Thanks! Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 16:43:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEL5-0003wI-B3; Fri, 20 May 2005 16:43:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEL4-0003wD-47 for ipv6@megatron.ietf.org; Fri, 20 May 2005 16:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12424 for ; Fri, 20 May 2005 16:43:19 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZEcT-0000U3-Tw for ipv6@ietf.org; Fri, 20 May 2005 17:01:23 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KKh7qa029531 for ; Fri, 20 May 2005 16:43:07 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KKh7YV105272 for ; Fri, 20 May 2005 16:43:07 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KKh7vV014767 for ; Fri, 20 May 2005 16:43:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KKh6lS014762; Fri, 20 May 2005 16:43:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4KKh1en023674; Fri, 20 May 2005 16:43:06 -0400 Message-Id: <200505202043.j4KKh1en023674@rotala.raleigh.ibm.com> To: Bob Hinden In-Reply-To: Message from bob.hinden@nokia.com of "Fri, 20 May 2005 13:29:51 PDT." <6.2.1.2.2.20050520131416.02c63f80@mailhost.iprg.nokia.com> Date: Fri, 20 May 2005 16:43:01 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ipv6@ietf.org Subject: Re: Proposed changes to IPv6 Address Architecture draft 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 about if it just says: > The high-order flag is reserved and must be zero. Actually, the issue that I'm trying to get around is to avoid having the spec say the flag "must be xxx" where xxx is any value. It should just (mostly) be ignored. If you say it must be zero, than some implementation might think if it is non-zero it should be changed to zero, or something equally silly. Thus, I think: The high-order flag is reserved. might be better than saying the full sentence. I.e., a future spec will set it to 1 and presumably all the existing implementations should continue doing what they did before hand -- i.e., just ignore the bit, not treating it having any special meaning one way or the other. With reserved fields in protocol headers, we typically say "ignored on receipt". But that is not true for an address, because the value isn't completely ignored, as its considered part of the address when doing lookups or when comparing against other addresses. But this is all a pretty minor point overall. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 16:53:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEV0-0006vh-Vy; Fri, 20 May 2005 16:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEUu-0006uq-18 for ipv6@megatron.ietf.org; Fri, 20 May 2005 16:53:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13024 for ; Fri, 20 May 2005 16:53:29 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZEmK-0000gT-17 for ipv6@ietf.org; Fri, 20 May 2005 17:11:33 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.11942463; Fri, 20 May 2005 16:53:01 -0400 In-Reply-To: <200505202043.j4KKh1en023674@rotala.raleigh.ibm.com> References: <200505202043.j4KKh1en023674@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <84d279f366e7d77e70416ac4db96ec3c@innovationslab.net> From: Brian Haberman Date: Fri, 20 May 2005 16:53:00 -0400 To: Thomas Narten X-Mailer: Apple Mail (2.622) X-esp: ESP<8>=RBL:<0> RDNS:<0> SHA:<8> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Bob Hinden , ipv6@ietf.org Subject: Re: Proposed changes to IPv6 Address Architecture draft 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="===============1312188787==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============1312188787== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11-876227604; protocol="application/pkcs7-signature" --Apple-Mail-11-876227604 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 20, 2005, at 16:43, Thomas Narten wrote: >> How about if it just says: > >> The high-order flag is reserved and must be zero. > > Actually, the issue that I'm trying to get around is to avoid having > the spec say the flag "must be xxx" where xxx is any value. It should > just (mostly) be ignored. If you say it must be zero, than some > implementation might think if it is non-zero it should be changed to > zero, or something equally silly. > > Thus, I think: > > The high-order flag is reserved. > > might be better than saying the full sentence. > > I.e., a future spec will set it to 1 and presumably all the existing > implementations should continue doing what they did before hand -- > i.e., just ignore the bit, not treating it having any special meaning > one way or the other. > > With reserved fields in protocol headers, we typically say "ignored on > receipt". But that is not true for an address, because the value isn't > completely ignored, as its considered part of the address when doing > lookups or when comparing against other addresses. > > But this is all a pretty minor point overall. > I emphatically agree that it is a minor point. The current text has been in the spec from day 1 and has not caused problems. Given that, I would prefer to leave the text as is. Regards, Brian --Apple-Mail-11-876227604 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTIwMjA1MzAxWjAjBgkqhkiG9w0B CQQxFgQUkGU1k7Gh+8JG2ntqrj96a9YD2+YweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAnI3M2mvnQDulgXS5fX9khoi/rLAu3an2CfJPsJy1ZmpTyWhSYgOKP6uJOpickC07Jj/0 TJnhmRhQhLt//x4AUwPof6PaKaypgT2Y6te4mYxlAkaqx3q7tTu7WilO8ooSsBqEDzv98nuURxxq 20dxOc2LSnExe57hGZ8B/xUqIL+ISvNnSW+qKqmk8ZAubwc1M5ASSPx23cGkjAjlOfPmpvLwMa2D CNinCDm/BbFBPqOwf1YkjuYWciEP49XLL8VwIqzFGN2uOh8sFT+JuHYUgJI+FTYMpWwkok2izHlf NS9Z2OFIIltoVh9skL+rVhDeiQQpbK3U+pDEOTWpMdiMtgAAAAAAAA== --Apple-Mail-11-876227604-- --===============1312188787== 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 -------------------------------------------------------------------- --===============1312188787==-- From ipv6-bounces@ietf.org Fri May 20 17: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 1DZEtq-0005qr-CW; Fri, 20 May 2005 17: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 1DZEto-0005qj-4v for ipv6@megatron.ietf.org; Fri, 20 May 2005 17:19:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15022 for ; Fri, 20 May 2005 17:19:13 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZFBC-0001GE-S8 for ipv6@ietf.org; Fri, 20 May 2005 17:37:17 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA09420; Fri, 20 May 2005 16:19:01 -0500 (CDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4KLJ1w28373; Fri, 20 May 2005 16:19:01 -0500 (CDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 May 2005 17:19:00 -0400 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: Fri, 20 May 2005 17:19:00 -0400 Message-ID: Thread-Topic: Proposed changes to IPv6 Address Architecture draft Thread-Index: AcVdfl/4Blq2b27XRWyw7zhgyeaAhAAAn9IQ From: "Manfredi, Albert E" To: "Brian Haberman" X-OriginalArrivalTime: 20 May 2005 21:19:00.0732 (UTC) FILETIME=[8A982BC0:01C55D81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: Proposed changes to IPv6 Address Architecture draft 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 would go further than Brian on this single point of the high order = flag bit. If you do not specify that it must be set to zero on transmission, then = in the future, when you do want to start using it, you'll be stuck with = having to modify servers, overnight, that haven't yet implemented that = flag. Other than that single item, I'm agreeing with Thomas. Bert > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Friday, May 20, 2005 3:53 PM > To: Thomas Narten > Cc: Bob Hinden; ipv6@ietf.org > Subject: Re: Proposed changes to IPv6 Address Architecture draft=20 >=20 >=20 >=20 > On May 20, 2005, at 16:43, Thomas Narten wrote: >=20 > >> How about if it just says: > > > >> The high-order flag is reserved and must be zero. > > > > Actually, the issue that I'm trying to get around is to avoid having > > the spec say the flag "must be xxx" where xxx is any value.=20 > It should > > just (mostly) be ignored. If you say it must be zero, than some > > implementation might think if it is non-zero it should be changed to > > zero, or something equally silly. > > > > Thus, I think: > > > > The high-order flag is reserved. > > > > might be better than saying the full sentence. > > > > I.e., a future spec will set it to 1 and presumably all the existing > > implementations should continue doing what they did before hand -- > > i.e., just ignore the bit, not treating it having any=20 > special meaning > > one way or the other. > > > > With reserved fields in protocol headers, we typically say=20 > "ignored on > > receipt". But that is not true for an address, because the=20 > value isn't > > completely ignored, as its considered part of the address when doing > > lookups or when comparing against other addresses. > > > > But this is all a pretty minor point overall. > > >=20 > I emphatically agree that it is a minor point. The current text has=20 > been > in the spec from day 1 and has not caused problems. Given that, > I would prefer to leave the text as is. >=20 > Regards, > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 20 19:15:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZGiW-0000A8-3v; Fri, 20 May 2005 19:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZGiT-00009a-SY; Fri, 20 May 2005 19:15:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25767; Fri, 20 May 2005 19:15:38 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZGzu-00045l-0S; Fri, 20 May 2005 19:33:44 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4KMiEs16748; Fri, 20 May 2005 15:44:14 -0700 X-mProtect: <200505202244> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdrIZsd3; Fri, 20 May 2005 15:44:12 PDT Message-Id: <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 20 May 2005 16:15:13 -0700 To: ipv6@ietf.org From: Bob Hinden In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dhcwg@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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, I would like to second the point Jinmei made, that we had something very close to this discussion about a year ago. Also, I am not sure I understand what the problem is regarding knowing when to try using DHCPv6. For practical purposes, if there isn't a router present (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 server either (or it won't be reachable because the router is down). If the "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host might try to use DHCPv6 and see what it gets. If the "m" or "o" bits are not set, then it's a pretty good hint that there isn't much sense in trying to use DHCPv6. Is something else needed? Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 21 07:19:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS1L-0002K9-7G; Sat, 21 May 2005 07:19:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS1J-0002Jg-AS; Sat, 21 May 2005 07:19:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29380; Sat, 21 May 2005 07:19:50 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZMKo-0000iN-IJ; Sat, 21 May 2005 01:15:40 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 728D189869; Sat, 21 May 2005 07:56:46 +0300 (EEST) Message-ID: <428EBF9C.8040008@kolumbus.fi> Date: Sat, 21 May 2005 07:57:00 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" Subject: Re: meta thoughts on m/o bits 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: >Hi Bernie, > > > > => You can try, but my concern is about how often you're > > going to try. > > > If there are bits that say whether you should try or not and those > > > bits are not set (i.e. no DHCP server in the network), why > > > would you try? > > > > This means that the wiresless operators will get more revenue from > > Ralph! > > > > If the wireless operator isn't using DHCP (or only using stateless), > > there's no reason they can't charge for that (stateful) traffic. > >=> :) I don't want them to charge users for Ralph's implementation :) >But seriously, charging is one thing, inefficient use of power is >another serious problem which can actually reduce revenue because >a device doesn't go dormant long enough and runs out of battery >instead of using that battery power for what the user actually wants >to do. > > I tend to agree with Hesham that we should attempt to design our protocols so that unnecessary periodic probing over wireless is minimized. One thing that should be kept in mind is that most people want their devices to be always on and reachable, but yet they might actually use them for something only a very small fraction of the time. Even a tiny amount of traffic during the inactive period may thus result in a relatively large impact when you compare it to actual useful traffic. This in turn translates to battery lifetimes and cost for the users. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 21 07:20:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS1Q-0002Mv-1x; Sat, 21 May 2005 07:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS1N-0002Le-JD; Sat, 21 May 2005 07:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29458; Sat, 21 May 2005 07:19:55 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZMFm-0006MV-3t; Sat, 21 May 2005 01:10:27 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4L4pYh21381; Sat, 21 May 2005 07:51:34 +0300 Date: Sat, 21 May 2005 07:51:34 +0300 (EEST) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> Message-ID: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@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: b19722fc8d3865b147c75ae2495625f2 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Fri, 20 May 2005, Bob Hinden wrote: > Also, I am not sure I understand what the problem is regarding knowing when > to try using DHCPv6. For practical purposes, if there isn't a router present > (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 > server either (or it won't be reachable because the router is down). If the > "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host > might try to use DHCPv6 and see what it gets. If the "m" or "o" bits are not > set, then it's a pretty good hint that there isn't much sense in trying to > use DHCPv6. Actually, the lack of M or O bits is not as good a hint as their existence. If we wanted a _good_ hint about non-existence of DHCPv6 (for addresses or config information), we'd have to have different flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in this network". That allows disambiguation from "Yes, we do have a couple of DHCPv6 servers, but we weren't aware you should configure this stuff in the RAs, because with v4 you don't". But I'm not sure that disambiguation is worth the effort. That said, I support the clarification. In a sense I agree with Thomas et al that the ra-mo-flags spec goes beyond the bare minimum what the IETF specifications must specify -- it documents the policies and behaviours which most vendors would implement in any case, but these kind of knobs have often been left out of our specs. However, as there has been so much confusion and discussion of M/O flags, I think this specification is useful, and also allows vendors (who want to) to implement the knobs in a uniform manner. -- 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 Sat May 21 07:24:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS5N-0003yc-D0; Sat, 21 May 2005 07:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZS5L-0003yV-E8 for ipv6@megatron.ietf.org; Sat, 21 May 2005 07:24:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02692 for ; Sat, 21 May 2005 07:24:02 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZJge-0002I7-JE for ipv6@ietf.org; Fri, 20 May 2005 22:26:00 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 19:07:31 -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); Fri, 20 May 2005 19:07:30 -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); Fri, 20 May 2005 19:07:30 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 19:07:30 -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: Fri, 20 May 2005 19:07:03 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC111A348EA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: ndproxy loop prevention thread-index: AcUqS5QVKU7Nw6m2TmiG72ItF80eaAzXWJLw From: "Dave Thaler" To: "Bob Hinden" , "Erik Nordmark" X-OriginalArrivalTime: 21 May 2005 02:07:30.0282 (UTC) FILETIME=[D7E3E4A0:01C55DA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Subject: RE: ndproxy loop prevention 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 Bib Hinden writes: > >This means that the STP-running sub-cloud need to be P-bit transparent, > right? >=20 > Yes, that is my understanding. I think the draft is consistent with > this. That is, a ND proxy implements either the P-bit (choice a) or the > STP (choice b) modes, but not both. In STP mode the P-bit (or any of the > other bits in the RA) isn't touched. >=20 > >Thus if there is an upstream which sets the P-bit, then any downstreams > >from the sub-cloud should receive the P-bit. > >To do that the ndproxy nodes which run STP need to behave quite > >differently than then ones that don't run STP. What are the exact rules > >for them? > >Are they > > - ignore any P-bit > > - make sure any RAs that are received with the P-bit set are proxied > > (transmitted) with the P-bit >=20 > Right, and I think that is the defined behavior of a proxy implementing > STP (i.e., they pass the P-bit setting through unchanged). >=20 > I think it would be good if another paragraph was added to Section 4.1.4.3 > "ICMPv6 Router Advertisements" that clarifies this behavior. Also, > something added to Section 6. "Loop Prevention" that explains the case of > a site with a mixture of proxies. I just submitted an update which should appear shortly, which incorporates the above suggestion, and changes "STP" to "RSTP" throughout in accordance with the 2004 bridge std from IEEE which updates STP and renames it to RSTP. Added to end of 4.1.4.3: > If, on the other hand, RSTP is implemented as described in section > 6, no special processing is done for RAs. That is, the P bit is > ignored, and the P bit is unmodified in RAs proxied to other > interfaces. Added to 6 (language very close to that in the thread on this list): > Note that it is possible that a site has a mixture of P bit > proxies and RSTP-capable proxies. To understand how this works, > consider the case where only P bit proxies are present. However, > within each link, there may be classic IEEE 802 bridges. Those > classic bridges are responsible for ensuring that that link is > loop-free. To P bit proxies, proxies which run RSTP are the same > in this respect as classic IEEE 802 bridges. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 21 09:21:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZTvH-0007xt-7h; Sat, 21 May 2005 09:21:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZTvF-0007xi-3S; Sat, 21 May 2005 09:21:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19816; Sat, 21 May 2005 09:21:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZUCo-0005Kk-Np; Sat, 21 May 2005 09:39:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 May 2005 09:21:36 -0400 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 j4LDLW4u029625; Sat, 21 May 2005 09:21:33 -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); Sat, 21 May 2005 09:21:32 -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: Sat, 21 May 2005 09:21:28 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3E07@xmb-rtp-20a.amer.cisco.com> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVd+f6Mv0pLKGdJTN2ZfxhSRfd5rAACtd1g From: "Bernie Volz \(volz\)" To: "Jari Arkko" , "Soliman, Hesham" X-OriginalArrivalTime: 21 May 2005 13:21:32.0888 (UTC) FILETIME=[018FD580:01C55E08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: meta thoughts on m/o bits 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 Look, I'm not advocating that every device run DHCPv6. I think we're all on the same page here - we want some indication of whether to run or not run DHCP, but that is only an indication not a hard requirement. I, as the owner/administrator of a device, should be able to explicitly configure the device to either always run DHCP or never run DHCP. If I chose to run it when there is no service available, so be it. If I chose to no run it when there is a service and it is needed for "full" network access, so be it -- my device may have limited access depending on what stateless allows or doesn't allow. Other than periodic traffic, which in many networks is of no significant consequence (though it *IS* in other networks), there is no harm if you err on the side or running DHCP ALWAYS. If on the other hand you do not run it when it is needed for full access ... There are many heuristics that can be used by devices to "guess" at whether DHCP might be useful to run or not. For example, if there are prefixes advertised but none are stateless, run DHCP. If all advertised prefixes are stateless, don't run DHCP (at least for stateful addresses). And, clients could be smarter about the retransmission algorithms they use -- such as using longer "probe" intervals if they fail to get a response. Or stopping the probes after a period of time.=20 Sure, all of this takes some processing overhead and that's why I think we all feel that having a bit or two bits as hints makes a lot of sense. I believe some people were very concerned if a router is misconfigured. Personally, I don't get that issue at all. If an administrator doesn't configure other things properly, the network may or may not work either. So, why are these bits any different than the hundreds of other parameters and knobs? Perhaps we should be discussing what routers might do to figure out how to automatically determine the setting of these bits or "alarm" if the bit is potentially set incorrectly? One simple rule is if the router is configured to be a relay agent, the bit(s) should be set. (At least if we take DHCPv4 networks as a model, this will likely properly configure a good portion of the routers correctly.) Perhaps the router should periodically probe for a DHCP server (via the link-local multicast address). If one is discovered and the bit(s) are clear, either there is a rogue server on the network OR the bit(s) wasn't configured correctly. If no server responds after some number of attempts and the bit(s) are set, either the server is down (in which case clearing the bit(s) in the RA might not be a big issue until the server returns -- modulo the probe interval) or the bits were set incorrectly and some type of "alarm" is reasonable. - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Jari Arkko > Sent: Saturday, May 21, 2005 12:57 AM > To: Soliman, Hesham > Cc: dhcwg@ietf.org; ipv6@ietf.org; Bernie Volz (volz); Ralph=20 > Droms (rdroms) > Subject: Re: meta thoughts on m/o bits >=20 > Soliman, Hesham wrote: >=20 > >Hi Bernie,=20 > > > > > > =3D> You can try, but my concern is about how often you're=20 > > > going to try. > > > > If there are bits that say whether you should try or=20 > not and those=20 > > > > bits are not set (i.e. no DHCP server in the network), why=20 > > > > would you try? > > > =20 > > > This means that the wiresless operators will get more revenue from > > > Ralph! > > >=20 > > > If the wireless operator isn't using DHCP (or only using=20 > stateless), > > > there's no reason they can't charge for that (stateful) traffic. > > > >=3D> :) I don't want them to charge users for Ralph's implementation = :) > >But seriously, charging is one thing, inefficient use of power is=20 > >another serious problem which can actually reduce revenue because > >a device doesn't go dormant long enough and runs out of battery=20 > >instead of using that battery power for what the user actually wants > >to do. > > =20 > > > I tend to agree with Hesham that we should attempt to design > our protocols so that unnecessary periodic probing over wireless > is minimized. One thing that should be kept in mind is that most > people want their devices to be always on and reachable, but yet > they might actually use them for something only a very small > fraction of the time. Even a tiny amount of traffic during the > inactive period may thus result in a relatively large impact > when you compare it to actual useful traffic. This in turn > translates to battery lifetimes and cost for the users. >=20 > --Jari >=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 Sun May 22 00:00:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZhdn-0008R8-JY; Sun, 22 May 2005 00:00:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZhdm-0008R1-4M for ipv6@megatron.ietf.org; Sun, 22 May 2005 00:00:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21167 for ; Sun, 22 May 2005 00:00:34 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZhvS-0000ix-EX for ipv6@ietf.org; Sun, 22 May 2005 00:18:55 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 6FF6B142 for ; Sun, 22 May 2005 00:00:18 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 22 May 2005 00:00:18 -0400 Message-Id: <20050522040018.6FF6B142@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 --------+------+--------+----------+------------------------ 13.16% | 10 | 16.72% | 78913 | volz@cisco.com 14.47% | 11 | 13.12% | 61930 | narten@us.ibm.com 14.47% | 11 | 11.86% | 55980 | bob.hinden@nokia.com 10.53% | 8 | 10.21% | 48195 | jinmei@isl.rdc.toshiba.co.jp 7.89% | 6 | 8.40% | 39638 | rdroms@cisco.com 5.26% | 4 | 9.20% | 43407 | brian@innovationslab.net 5.26% | 4 | 6.65% | 31380 | h.soliman@flarion.com 3.95% | 3 | 3.74% | 17642 | smadanapalli@gmail.com 3.95% | 3 | 2.46% | 11617 | pekkas@netcore.fi 2.63% | 2 | 3.36% | 15866 | eric.gray@marconi.com 2.63% | 2 | 2.48% | 11710 | timbeck04@verizon.net 2.63% | 2 | 2.14% | 10097 | jim.bound@hp.com 1.32% | 1 | 1.68% | 7911 | syam@samsung.com 1.32% | 1 | 1.20% | 5672 | dthaler@windows.microsoft.com 1.32% | 1 | 1.14% | 5383 | albert.e.manfredi@boeing.com 1.32% | 1 | 0.90% | 4267 | jari.arkko@kolumbus.fi 1.32% | 1 | 0.85% | 4011 | margaret@thingmagic.com 1.32% | 1 | 0.81% | 3843 | sra+ipng@hactrn.net 1.32% | 1 | 0.80% | 3789 | sharkey@zoic.org 1.32% | 1 | 0.79% | 3747 | stig.venaas@uninett.no 1.32% | 1 | 0.74% | 3483 | gdemarco@unisa.it 1.32% | 1 | 0.72% | 3383 | ipng@69706e6720323030352d30312d31340a.nosense.org --------+------+--------+----------+------------------------ 100.00% | 76 |100.00% | 471864 | 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 Sun May 22 13:14:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZu1m-00082h-5F; Sun, 22 May 2005 13:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZu1l-00082a-3u for ipv6@megatron.ietf.org; Sun, 22 May 2005 13:14:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03802 for ; Sun, 22 May 2005 13:14:09 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZuJY-00074q-1L for ipv6@ietf.org; Sun, 22 May 2005 13:32:37 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4MHED2Z014779 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 22 May 2005 19:14:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF IPv6 Mailing List From: Iljitsch van Beijnum Date: Sun, 22 May 2005 19:13:59 +0200 X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: Strange multicast 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, Maybe this is a stupid question but I'm stumped... And if this isn't the appropriate forum, I apologize but I can't think of another place to ask this. When I execute the netstat -ia command on my FreeBSD or MacOS system, I see: xl0 1500 2001:1af8:2 2001:1af8:2:5::2 33034 - 2866 - - ff02:1::1:ff00:2 (refs: 1) ff02:1::2:5b81:5275(refs: 1) ff02:1::1 (refs: 1) ff02:1::1:ff29:2640(refs: 1) The first and last multicast addresses are the solicited node addresses for IPv6 addresses on this interface (never mind the encoded scope zone identifier), and the ff02:1::1 address is the all- hosts multicast address. But what about the ff02:1::2:5b81:5275 address? This range doesn't show up on http://www.iana.org/assignments/ipv6-multicast-addresses and I can't find any application that is listening for this address. On the other system it's a different address, but also in ff02:x:: 2:0:0/96. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun May 22 14: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 1DZvIA-0000JR-4G; Sun, 22 May 2005 14: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 1DZvI8-0000JE-El for ipv6@megatron.ietf.org; Sun, 22 May 2005 14:35:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11678 for ; Sun, 22 May 2005 14:35:10 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZvZu-0002RY-Ce for ipv6@ietf.org; Sun, 22 May 2005 14:53:37 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:9db3:3622:87d3:fa36]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1C74615218; Mon, 23 May 2005 03:37:26 +0900 (JST) Date: Mon, 23 May 2005 03:35:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF IPv6 Mailing List Subject: Re: Strange multicast 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 Sun, 22 May 2005 19:13:59 +0200, >>>>> Iljitsch van Beijnum said: > xl0 1500 2001:1af8:2 2001:1af8:2:5::2 33034 - 2866 > - - > ff02:1::1:ff00:2 (refs: 1) > ff02:1::2:5b81:5275(refs: 1) > ff02:1::1 (refs: 1) > ff02:1::1:ff29:2640(refs: 1) (snip) > But what about the ff02:1::2:5b81:5275 address? This range doesn't > show up on http://www.iana.org/assignments/ipv6-multicast-addresses > and I can't find any application that is listening for this address. > On the other system it's a different address, but also in ff02:x:: > 2:0:0/96. It's most likely the MD5-hashed multicast group derived from the host name (See Section 5 of draft-ietf-ipngwg-icmp-name-lookups-11.txt.) The kernel automatically joins the group (like ff02::1 or solicited-node multicast addresses), so it's not surprising that you cannot find any application that explicitly joins the group. 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 Mon May 23 05:24:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9AP-0004A0-0k; Mon, 23 May 2005 05:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9AN-00049p-9g; Mon, 23 May 2005 05:24:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07026; Mon, 23 May 2005 05:24:05 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da9SJ-0008Jc-6A; Mon, 23 May 2005 05:42:40 -0400 Received: from esebh106.NOE.Nokia.com ([172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4N9O3pU031423; Mon, 23 May 2005 12:24:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:03 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:03 +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: Mon, 23 May 2005 12:24:02 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D2C789A@esebe100.NOE.Nokia.com> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVd+PXnWeuIho+8Q9mlrxw/wNvCJgBZxaYA To: , X-OriginalArrivalTime: 23 May 2005 09:24:03.0043 (UTC) FILETIME=[28D18B30:01C55F79] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Pekka and Bob, > On Fri, 20 May 2005, Bob Hinden wrote: > > Also, I am not sure I understand what the problem is regarding = knowing when=20 > > to try using DHCPv6. For practical purposes, if there isn't a = router present=20 > > (indicated by the RAs it sends) is very unlikely that there will be = a DHCPv6=20 > > server either (or it won't be reachable because the router is down). = If the=20 > > "m" and/or "o" bits are set in a RA, it is a pretty good hint that a = host=20 > > might try to use DHCPv6 and see what it gets. If the "m" or "o" = bits are not=20 > > set, then it's a pretty good hint that there isn't much sense in = trying to=20 > > use DHCPv6. >=20 > Actually, the lack of M or O bits is not as good a hint as their=20 > existence. If we wanted a _good_ hint about non-existence of DHCPv6=20 > (for addresses or config information), we'd have to have different=20 > flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in = > this network". That allows disambiguation from "Yes, we do have a=20 > couple of DHCPv6 servers, but we weren't aware you should configure=20 > this stuff in the RAs, because with v4 you don't". >=20 > But I'm not sure that disambiguation is worth the effort. >=20 > That said, I support the clarification. In a sense I agree with=20 > Thomas et al that the ra-mo-flags spec goes beyond the bare minimum=20 > what the IETF specifications must specify -- it documents the policies = > and behaviours which most vendors would implement in any case, but=20 > these kind of knobs have often been left out of our specs. However,=20 > as there has been so much confusion and discussion of M/O flags, I=20 > think this specification is useful, and also allows vendors (who want=20 > to) to implement the knobs in a uniform manner. I'll have to re-read the draft, but I think that documenting the M/O = bits sufficiently so that nodes and networks will be able to interoperate in a reasonable way. Documenting the basic policies and rules, IMO, are a good thing. Would a BCP-type document be a reasonable way to=20 achieve this? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 05:24:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9AX-0004Ad-8D; Mon, 23 May 2005 05:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9AU-0004AV-Qu; Mon, 23 May 2005 05:24:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07029; Mon, 23 May 2005 05:24:12 -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.33) id 1Da9SQ-0008Jh-O8; Mon, 23 May 2005 05:42:48 -0400 Received: from esebh108.NOE.Nokia.com ([172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4N9MIDZ008424; Mon, 23 May 2005 12:22:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:08 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 12:24:06 +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: Mon, 23 May 2005 12:24:05 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVd+gA/g6lcDZcHSPy124tMuAAX2gBZm7uw To: , X-OriginalArrivalTime: 23 May 2005 09:24:06.0277 (UTC) FILETIME=[2ABF0350:01C55F79] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org, volz@cisco.com, rdroms@cisco.com Subject: RE: meta thoughts on m/o bits 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 Jari & Hesham, > >=3D> :) I don't want them to charge users for Ralph's implementation = :) > >But seriously, charging is one thing, inefficient use of power is=20 > >another serious problem which can actually reduce revenue because > >a device doesn't go dormant long enough and runs out of battery=20 > >instead of using that battery power for what the user actually wants > >to do. > > =20 > > > I tend to agree with Hesham that we should attempt to design > our protocols so that unnecessary periodic probing over wireless > is minimized. One thing that should be kept in mind is that most > people want their devices to be always on and reachable, but yet > they might actually use them for something only a very small > fraction of the time. Even a tiny amount of traffic during the > inactive period may thus result in a relatively large impact > when you compare it to actual useful traffic. This in turn > translates to battery lifetimes and cost for the users. Basically, what I think we'd like is that if a device has a working address and is 'attached' to a network, it should probably use that address and only probe upon some failure event. When the device shows up to a new network, it can probe and if it gets a DHCP address, then use it, and update the address before the lease expires. If the device gets a valid address via autoconfig, then it should continue to use that. It doesn't make much sense that a node should continually verify if it should use a DHCP address if it has an otherwise working address. Note that many applications will run sometime of watchdog or heartbeat to ensure that application is still alive on both ends. If this fails, that might be a clue to check if the IP address is still valid. I agree that having probing at multiple layers is a bad design, IMO. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 06:38:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaAKO-0003l1-LO; Mon, 23 May 2005 06:38:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaAKN-0003kd-7J for ipv6@megatron.ietf.org; Mon, 23 May 2005 06:38:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11755 for ; Mon, 23 May 2005 06:38:28 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaAcJ-00069I-S4 for ipv6@ietf.org; Mon, 23 May 2005 06:57:05 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4NAcb2Z026922 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 May 2005 12:38:37 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <5F979DAE-1D39-4C85-96F3-75BD9E7DA71B@muada.com> Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Date: Mon, 23 May 2005 12:38:23 +0200 To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_00,BODY_8BITS, ILJQX_TO_UTF8 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: IETF IPv6 Mailing List Subject: Re: Strange multicast 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 22-mei-2005, at 20:35, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: >> But what about the ff02:1::2:5b81:5275 address? This range doesn't >> show up on http://www.iana.org/assignments/ipv6-multicast-addresses >> and I can't find any application that is listening for this address. >> On the other system it's a different address, but also in ff02:x:: >> 2:0:0/96. > It's most likely the MD5-hashed multicast group derived from the host > name (See Section 5 of draft-ietf-ipngwg-icmp-name-lookups-11.txt.) > The kernel automatically joins the group (like ff02::1 or > solicited-node multicast addresses), so it's not surprising that you > cannot find any application that explicitly joins the group. Right, thanks! It would be helpful if this address range were registered with the =20 IANA, though... For anyone else who wants to know more: have a look at a KAME ping6 =20 man page: http://developer.apple.com/documentation/Darwin/Reference/=20 ManPages/man8/ping6.8.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 07:46:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBOC-0002CZ-2Q; Mon, 23 May 2005 07:46:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBOA-0002CL-D4; Mon, 23 May 2005 07:46:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16535; Mon, 23 May 2005 07:46:29 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaBg6-0000eT-Mi; Mon, 23 May 2005 08:05:05 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 07:46:20 -0400 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 j4NBkGl6008830; Mon, 23 May 2005 07:46:16 -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); Mon, 23 May 2005 07:46:15 -0400 Received: from 10.86.240.55 ([10.86.240.55]) 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 ; Mon, 23 May 2005 11:46:15 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 07:46:38 -0400 From: Ralph Droms To: john.loughney@nokia.com In-Reply-To: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 07:46:37 -0400 Message-Id: <1116848797.5528.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 11:46:15.0901 (UTC) FILETIME=[06CC58D0:01C55F8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, jari.arkko@kolumbus.fi, ipv6@ietf.org, volz@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] RE: meta thoughts on m/o bits 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 John - My understanding is that the selection of SLAAC addresses is separate from the use of DHCP; that is, a host may be in a scenario in which it uses both an address chosen through SLAAC and an address assigned through a DHCP message exchange. So, the availability of a SLAAC address should not affect the use of DHCP. - Ralph On Mon, 2005-05-23 at 12:24 +0300, john.loughney@nokia.com wrote: > Jari & Hesham, > > > >=> :) I don't want them to charge users for Ralph's implementation :) > > >But seriously, charging is one thing, inefficient use of power is > > >another serious problem which can actually reduce revenue because > > >a device doesn't go dormant long enough and runs out of battery > > >instead of using that battery power for what the user actually wants > > >to do. > > > > > > > > I tend to agree with Hesham that we should attempt to design > > our protocols so that unnecessary periodic probing over wireless > > is minimized. One thing that should be kept in mind is that most > > people want their devices to be always on and reachable, but yet > > they might actually use them for something only a very small > > fraction of the time. Even a tiny amount of traffic during the > > inactive period may thus result in a relatively large impact > > when you compare it to actual useful traffic. This in turn > > translates to battery lifetimes and cost for the users. > > Basically, what I think we'd like is that if a device has a working > address and is 'attached' to a network, it should probably use that > address and only probe upon some failure event. When the device > shows up to a new network, it can probe and if it gets a DHCP address, > then use it, and update the address before the lease expires. If > the device gets a valid address via autoconfig, then it should continue > to use that. It doesn't make much sense that a node should continually > verify if it should use a DHCP address if it has an otherwise working > address. > > Note that many applications will run sometime of watchdog or heartbeat > to ensure that application is still alive on both ends. If this fails, > that might be a clue to check if the IP address is still valid. I > agree that having probing at multiple layers is a bad design, IMO. > > John > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 07:50:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBSS-0002wW-F1; Mon, 23 May 2005 07:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaBSQ-0002w2-6V; Mon, 23 May 2005 07:50:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16966; Mon, 23 May 2005 07:50:53 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaBkN-0000l4-HV; Mon, 23 May 2005 08:09:28 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 07:50:45 -0400 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 j4NBoY52016172; Mon, 23 May 2005 07:50:41 -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); Mon, 23 May 2005 07:50:36 -0400 Received: from 10.86.240.55 ([10.86.240.55]) 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 ; Mon, 23 May 2005 11:50:35 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 07:50:58 -0400 From: Ralph Droms To: john.loughney@nokia.com In-Reply-To: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> References: <1AA39B75171A7144A73216AED1D7478D2C789B@esebe100.NOE.Nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 07:50:58 -0400 Message-Id: <1116849058.5528.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 11:50:36.0106 (UTC) FILETIME=[A1E47AA0:01C55F8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, jari.arkko@kolumbus.fi, ipv6@ietf.org, volz@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] RE: meta thoughts on m/o bits 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 John - I agree that in lieu of some failure or otherwise special condition, devices should use the mechanisms built into SLAAC and DHCP (address lifetimes) to control the use and assignment of addresses. I think the DNAv6 work may have some impact on this discussion as providing a more reliable mechanism for detecting when a host has changed links and should therefore consider re-checking its addresses. - Ralph On Mon, 2005-05-23 at 12:24 +0300, john.loughney@nokia.com wrote: > Jari & Hesham, > > > >=> :) I don't want them to charge users for Ralph's implementation :) > > >But seriously, charging is one thing, inefficient use of power is > > >another serious problem which can actually reduce revenue because > > >a device doesn't go dormant long enough and runs out of battery > > >instead of using that battery power for what the user actually wants > > >to do. > > > > > > > > I tend to agree with Hesham that we should attempt to design > > our protocols so that unnecessary periodic probing over wireless > > is minimized. One thing that should be kept in mind is that most > > people want their devices to be always on and reachable, but yet > > they might actually use them for something only a very small > > fraction of the time. Even a tiny amount of traffic during the > > inactive period may thus result in a relatively large impact > > when you compare it to actual useful traffic. This in turn > > translates to battery lifetimes and cost for the users. > > Basically, what I think we'd like is that if a device has a working > address and is 'attached' to a network, it should probably use that > address and only probe upon some failure event. When the device > shows up to a new network, it can probe and if it gets a DHCP address, > then use it, and update the address before the lease expires. If > the device gets a valid address via autoconfig, then it should continue > to use that. It doesn't make much sense that a node should continually > verify if it should use a DHCP address if it has an otherwise working > address. > > Note that many applications will run sometime of watchdog or heartbeat > to ensure that application is still alive on both ends. If this fails, > that might be a clue to check if the IP address is still valid. I > agree that having probing at multiple layers is a bad design, IMO. > > John > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 08:49:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCNI-0001Ai-92; Mon, 23 May 2005 08:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCNG-0001Aa-8R; Mon, 23 May 2005 08:49:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21391; Mon, 23 May 2005 08:49:37 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaCfE-0002F8-M2; Mon, 23 May 2005 09:08:13 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4NCmc2Z029105 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 May 2005 14:48:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1116615963.11164.60.camel@localhost.localdomain> References: <1116615963.11164.60.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <668F63E6-A4E0-4993-8E9C-DDAF7553C572@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Mon, 23 May 2005 14:48:24 +0200 To: Ralph Droms X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: meta thoughts on m/o bits 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 20-mei-2005, at 21:06, Ralph Droms wrote: >> In some scenarios there is a danger in the following approach: >> - hosts boots >> - looks for DHCP server, doesn't find one >> - Keeps looking every couple of minutes Yes, this would clearly be harmful in cases where hosts both use DHCPv6 and stateless autoconfiguration, but no DHCPv6 server is available. This especially adds up when there are many hosts on the subnet. > A client is free to use some other timeout (2 hours instead of 2 > minutes?) if it chooses. How is this useful? Either I want to know that a DHCPv6 server has become available, so waiting 2 hours is way too long, or I don't care, so why bother checking in the first place? The situation where a server broadcasts its existence makes MUCH more sense. But the real question is: how do we know we want to use DHCPv6 in the first place? Obviously in many cases the answer is simple: yes, I want it all the time, or no, I never want it. But suppose some networks adopt DHCPv6 in lieu of stateless autoconfiguration for reasons that make sense to them (and work elsewhere, such as shim6, _may_ make this a somewhat more likely situation). It would then make sense for a laptop or similar client to have both stateless autoconfiguration and DHCPv6 on board for autoconfiguration. However, such a client wouldn't have any idea about the availability of either mechanism or their preference. Since presumably, DHCPv6 won't be available in many cases, an agnostic host wouldn't want to wait for DHCPv6 to fail when stateless autoconfig is available. On the other hand, some admins may strongly prefer hosts to use DHCPv6, but provide stateless autoconfig as a fallback for hosts that don't support DHCPv6. In that case, it would be better to ignore stateless autoconfig altogether when DHCPv6 works. The real problems start when DHCPv6 is preferred, but there is some kind of failure. Obviously the host should use stateless autoconfig in the mean time, but it would be useful if it were to switch to DHCPv6 as soon as the server becomes available. So what we really need is a mechanism that says: - DHCPv6 isn't available so don't bother with it - DHCPv6 is available, but use stateless autoconfig unless you can't/ won't - DHCPv6 is available and equal to stateless autoconfig, use either but no need to use both - DHCPv6 is available and equal to stateless autoconfig, use both - DHCPv6 is available and preferred, use it exclusively if you can Something similar is probably needed for the O flag. In addition, it would be useful to have some kind of flag that indicates that the DHCPv6 server status has changed so hosts should refresh their leases and other information. Obviously all of this can't be accommodated with two bits in RAs. So we can: - forget the whole thing and let the implementers/admins figure it out - hammer on it until it fits in the m and o bits - come up with an RA/ND option that has room for all of this (It would be cool to find a way to integrate DHCPv6 and RAs to some degree, though. For instance, by allowing DHCP options in RA options.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 08:53:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCR9-0001cc-9b; Mon, 23 May 2005 08:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCR0-0001by-6r; Mon, 23 May 2005 08:53:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21584; Mon, 23 May 2005 08:53:29 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaCiy-0002MM-V3; Mon, 23 May 2005 09:12:05 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id AFD3C109; Mon, 23 May 2005 08:51:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 08:53:16 -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: Mon, 23 May 2005 08:53:12 -0400 Message-ID: <936A4045C332714F975800409DE092404A0685@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: meta thoughts on m/o bits Thread-Index: AcVfjbnM79g3LMLJRxe5dyBP+G2CugACJkVA From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 23 May 2005 12:53:16.0459 (UTC) FILETIME=[633CCFB0:01C55F96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: H.Soliman@flarion.com, jari.arkko@kolumbus.fi, ipv6@ietf.org, volz@cisco.com, dhcwg@ietf.org Subject: RE: [dhcwg] RE: meta thoughts on m/o bits 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 my understanding too and the way it should be implemented too. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Ralph Droms > Sent: Monday, May 23, 2005 7:47 AM > To: john.loughney@nokia.com > Cc: H.Soliman@flarion.com; jari.arkko@kolumbus.fi;=20 > ipv6@ietf.org; volz@cisco.com; dhcwg@ietf.org > Subject: Re: [dhcwg] RE: meta thoughts on m/o bits >=20 > John - My understanding is that the selection of SLAAC addresses is > separate from the use of DHCP; that is, a host may be in a scenario in > which it uses both an address chosen through SLAAC and an address > assigned through a DHCP message exchange. So, the availability of a > SLAAC address should not affect the use of DHCP. >=20 > - Ralph >=20 > On Mon, 2005-05-23 at 12:24 +0300, john.loughney@nokia.com wrote:=20 > > Jari & Hesham, > >=20 > > > >=3D> :) I don't want them to charge users for Ralph's=20 > implementation :) > > > >But seriously, charging is one thing, inefficient use of=20 > power is=20 > > > >another serious problem which can actually reduce revenue because > > > >a device doesn't go dormant long enough and runs out of battery=20 > > > >instead of using that battery power for what the user=20 > actually wants > > > >to do. > > > > =20 > > > > > > > I tend to agree with Hesham that we should attempt to design > > > our protocols so that unnecessary periodic probing over wireless > > > is minimized. One thing that should be kept in mind is that most > > > people want their devices to be always on and reachable, but yet > > > they might actually use them for something only a very small > > > fraction of the time. Even a tiny amount of traffic during the > > > inactive period may thus result in a relatively large impact > > > when you compare it to actual useful traffic. This in turn > > > translates to battery lifetimes and cost for the users. > >=20 > > Basically, what I think we'd like is that if a device has a working > > address and is 'attached' to a network, it should probably use that > > address and only probe upon some failure event. When the device > > shows up to a new network, it can probe and if it gets a=20 > DHCP address, > > then use it, and update the address before the lease expires. If > > the device gets a valid address via autoconfig, then it=20 > should continue > > to use that. It doesn't make much sense that a node should=20 > continually > > verify if it should use a DHCP address if it has an=20 > otherwise working > > address. > >=20 > > Note that many applications will run sometime of watchdog=20 > or heartbeat > > to ensure that application is still alive on both ends. If=20 > this fails, > > that might be a clue to check if the IP address is still valid. I > > agree that having probing at multiple layers is a bad design, IMO. > >=20 > > John > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg >=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 Mon May 23 08:57:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCVL-0002HA-I9; Mon, 23 May 2005 08:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaCVG-0002G4-4I; Mon, 23 May 2005 08:57:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22015; Mon, 23 May 2005 08:57:53 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaCnE-0002UT-Ru; Mon, 23 May 2005 09:16:29 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8C626FE; Mon, 23 May 2005 08:55:35 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 08:57:44 -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: Mon, 23 May 2005 08:57:41 -0400 Message-ID: <936A4045C332714F975800409DE092404A068B@tayexc14.americas.cpqcorp.net> Thread-Topic: meta thoughts on m/o bits Thread-Index: AcVflh0XeIjvY7pMRzypU2y4/5aAWQAAH2uQ From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Ralph Droms" X-OriginalArrivalTime: 23 May 2005 12:57:44.0668 (UTC) FILETIME=[031A41C0:01C55F97] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: RE: meta thoughts on m/o bits 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 know what is complex here this is all obvious today with current wording. Even if DHCPv6 is used for addresses, statless is still required as a note too. This is not an implementation problem I see at all. =20 Of those speaking how many of you when writing your code got stuck and that might help this discussion? This has been going on to long. Our specs need to work whether someone uses them or not that is not our job here. =20 thanks /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Iljitsch van Beijnum > Sent: Monday, May 23, 2005 8:48 AM > To: Ralph Droms > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: Re: meta thoughts on m/o bits >=20 > On 20-mei-2005, at 21:06, Ralph Droms wrote: >=20 > >> In some scenarios there is a danger in the following approach: > >> - hosts boots > >> - looks for DHCP server, doesn't find one > >> - Keeps looking every couple of minutes >=20 > Yes, this would clearly be harmful in cases where hosts both use =20 > DHCPv6 and stateless autoconfiguration, but no DHCPv6 server is =20 > available. This especially adds up when there are many hosts on the =20 > subnet. >=20 > > A client is free to use some other timeout (2 hours instead of 2 > > minutes?) if it chooses. >=20 > How is this useful? Either I want to know that a DHCPv6 server has =20 > become available, so waiting 2 hours is way too long, or I don't =20 > care, so why bother checking in the first place? >=20 > The situation where a server broadcasts its existence makes=20 > MUCH more =20 > sense. >=20 > But the real question is: how do we know we want to use=20 > DHCPv6 in the =20 > first place? Obviously in many cases the answer is simple: yes, I =20 > want it all the time, or no, I never want it. >=20 > But suppose some networks adopt DHCPv6 in lieu of stateless =20 > autoconfiguration for reasons that make sense to them (and work =20 > elsewhere, such as shim6, _may_ make this a somewhat more likely =20 > situation). It would then make sense for a laptop or similar client =20 > to have both stateless autoconfiguration and DHCPv6 on board for =20 > autoconfiguration. However, such a client wouldn't have any idea =20 > about the availability of either mechanism or their=20 > preference. Since =20 > presumably, DHCPv6 won't be available in many cases, an=20 > agnostic host =20 > wouldn't want to wait for DHCPv6 to fail when stateless=20 > autoconfig is =20 > available. On the other hand, some admins may strongly prefer hosts =20 > to use DHCPv6, but provide stateless autoconfig as a fallback for =20 > hosts that don't support DHCPv6. In that case, it would be better to =20 > ignore stateless autoconfig altogether when DHCPv6 works. The real =20 > problems start when DHCPv6 is preferred, but there is some kind of =20 > failure. Obviously the host should use stateless autoconfig in the =20 > mean time, but it would be useful if it were to switch to DHCPv6 as =20 > soon as the server becomes available. >=20 > So what we really need is a mechanism that says: >=20 > - DHCPv6 isn't available so don't bother with it > - DHCPv6 is available, but use stateless autoconfig unless you can't/=20 > won't > - DHCPv6 is available and equal to stateless autoconfig, use either =20 > but no need to use both > - DHCPv6 is available and equal to stateless autoconfig, use both > - DHCPv6 is available and preferred, use it exclusively if you can >=20 > Something similar is probably needed for the O flag. >=20 > In addition, it would be useful to have some kind of flag that =20 > indicates that the DHCPv6 server status has changed so hosts should =20 > refresh their leases and other information. >=20 > Obviously all of this can't be accommodated with two bits in RAs. So =20 > we can: >=20 > - forget the whole thing and let the implementers/admins figure it out > - hammer on it until it fits in the m and o bits > - come up with an RA/ND option that has room for all of this >=20 > (It would be cool to find a way to integrate DHCPv6 and RAs to some =20 > degree, though. For instance, by allowing DHCP options in RA options.) >=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 Mon May 23 12:49:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaG7L-0003QP-Qy; Mon, 23 May 2005 12:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaG7K-0003Pn-4O; Mon, 23 May 2005 12:49:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13146; Mon, 23 May 2005 12:49:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGPJ-0003IU-TZ; Mon, 23 May 2005 13:08:03 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4NGHiT08143; Mon, 23 May 2005 09:17:44 -0700 X-mProtect: <200505231617> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp164186.americas.nokia.com (10.241.164.186, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdCBGJ0h; Mon, 23 May 2005 09:17:42 PDT Message-Id: <6.2.1.2.2.20050523093529.0282cd70@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 23 May 2005 09:48:50 -0700 To: Pekka Savola From: Bob Hinden In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@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: 8b30eb7682a596edff707698f4a80f7d Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Pekka, >Actually, the lack of M or O bits is not as good a hint as their >existence. If we wanted a _good_ hint about non-existence of DHCPv6 (for >addresses or config information), we'd have to have different flag(s) like >"Yes, I'm aware of what DHCPv6 is, but we don't use it in this >network". That allows disambiguation from "Yes, we do have a couple of >DHCPv6 servers, but we weren't aware you should configure this stuff in >the RAs, because with v4 you don't". This still seems to be to be fairly equivalent. I think the important function is if there is a DHCPv6 server and the site want the clients to use it, then they should set the "m" and "o" bits. I don't see very much value in conveying the negatives (e.g., we have a DHCPv6 server, but we don't want the clients to use it, we don't have a DHCPv6 server so don't try looking for one, we didn't set up a relay, etc., etc.). >But I'm not sure that disambiguation is worth the effort. Agreed. >That said, I support the clarification. In a sense I agree with Thomas et >al that the ra-mo-flags spec goes beyond the bare minimum what the IETF >specifications must specify -- it documents the policies and behaviours >which most vendors would implement in any case, but these kind of knobs >have often been left out of our specs. However, as there has been so much >confusion and discussion of M/O flags, I think this specification is >useful, and also allows vendors (who want to) to implement the knobs in a >uniform manner. Part of me is starting to think that we might be better off waiting for there to be more operational experience with deployments of DHCPv6 to see how much confusion there really is. I agree it is good for vendors to implement similar knobs, but I wonder how much of a problem there really is. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 13:15:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGWX-00069m-A3; Mon, 23 May 2005 13:15:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGWV-00069e-FD; Mon, 23 May 2005 13:15:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15496; Mon, 23 May 2005 13:15:24 -0400 (EDT) Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGoV-0004Q2-EY; Mon, 23 May 2005 13:34:04 -0400 Received: from alerion.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id j4NHFBp16502; Mon, 23 May 2005 10:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id D0E093F0021; Mon, 23 May 2005 10:15:11 -0700 (PDT) Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13309-10; Mon, 23 May 2005 10:15:10 -0700 (PDT) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id C09AA3F0020; Mon, 23 May 2005 10:15:10 -0700 (PDT) From: Tim Hartrick To: Bob Hinden In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1116868160.22946.13.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 May 2005 10:09:20 -0700 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@mentat.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 Bob, On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > > Part of me is starting to think that we might be better off waiting for > there to be more operational experience with deployments of DHCPv6 to see > how much confusion there really is. I agree it is good for vendors to > implement similar knobs, but I wonder how much of a problem there really is. > More than part of me is thinking this. It seems to me that there is a continuing confusion about how these bits interact with local decisions by the administrator of a specific machine or network. People are asking questions like "What happens if the M and/or O bits are clear but there is a DHCP server?" or "What happens if the M and/or O bits are clear but the client wants to use DHCP anyway" or "What happens if the M and/or O bits are set and the client doesn't want to run DHCP". None of these questions are in the realm of protocol design. Clearly, local administrators will do as they please with their machines. In this respect the M and O bits have never been anything but strong hints as to what the client should do. The client is always free to ignore the hints. Further network administrators are free to misconfigure their networks as they please. The current text describing these bits is clear almost to the point of being infantile. This isn't an indictment of the authors. Rather it is an indictment of attempts to enforce system configuration and management rules via protocol specifications. This is impossible. We should stop trying. tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 14:22:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHYv-0006TF-85; Mon, 23 May 2005 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHYs-0006Sw-Se; Mon, 23 May 2005 14:21:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24089; Mon, 23 May 2005 14:21:57 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHqu-0007Hz-Dp; Mon, 23 May 2005 14:40:36 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 May 2005 11:21:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j4NIKv3w028585; Mon, 23 May 2005 11:21:46 -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); Mon, 23 May 2005 14:21:45 -0400 Received: from 10.86.242.29 ([10.86.242.29]) 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 ; Mon, 23 May 2005 18:21:44 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 14:22:09 -0400 From: Ralph Droms To: Pekka Savola In-Reply-To: References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 08:50:44 -0400 Message-Id: <1116852645.5655.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 18:21:45.0156 (UTC) FILETIME=[46895040:01C55FC4] X-Spam-Score: 0.7 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: Re: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Sat, 2005-05-21 at 07:51 +0300, Pekka Savola wrote: > On Fri, 20 May 2005, Bob Hinden wrote: > > Also, I am not sure I understand what the problem is regarding knowing when > > to try using DHCPv6. For practical purposes, if there isn't a router present > > (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 > > server either (or it won't be reachable because the router is down). If the > > "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host > > might try to use DHCPv6 and see what it gets. If the "m" or "o" bits are not > > set, then it's a pretty good hint that there isn't much sense in trying to > > use DHCPv6. > > Actually, the lack of M or O bits is not as good a hint as their > existence. If we wanted a _good_ hint about non-existence of DHCPv6 > (for addresses or config information), we'd have to have different > flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in > this network". That allows disambiguation from "Yes, we do have a > couple of DHCPv6 servers, but we weren't aware you should configure > this stuff in the RAs, because with v4 you don't". Huh? > But I'm not sure that disambiguation is worth the effort. > > That said, I support the clarification. In a sense I agree with > Thomas et al that the ra-mo-flags spec goes beyond the bare minimum > what the IETF specifications must specify -- it documents the policies > and behaviours which most vendors would implement in any case, but > these kind of knobs have often been left out of our specs. However, > as there has been so much confusion and discussion of M/O flags, I > think this specification is useful, and also allows vendors (who want > to) to implement the knobs in a uniform manner. So which do you recomend - a minimum spec like Bob and Thomas have suggested or a more detailed spec like the current ra-mo draft? - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 14:46:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHwc-0001AU-UQ; Mon, 23 May 2005 14:46:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHwb-0001AM-4x; Mon, 23 May 2005 14:46:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26606; Mon, 23 May 2005 14:46:28 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIEc-0008Dt-5E; Mon, 23 May 2005 15:05:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 14:46:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4NIjdle014215; Mon, 23 May 2005 14:46:16 -0400 (EDT) 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); Mon, 23 May 2005 14:46:12 -0400 Received: from 10.86.242.29 ([10.86.242.29]) 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 ; Mon, 23 May 2005 18:46:12 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 14:46:36 -0400 From: Ralph Droms To: tim@mentat.com In-Reply-To: <1116868160.22946.13.camel@feller> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <1116868160.22946.13.camel@feller> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 14:46:36 -0400 Message-Id: <1116873996.5397.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 18:46:12.0756 (UTC) FILETIME=[B14B4D40:01C55FC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Tim - I agree 100% with your message. - Ralph On Mon, 2005-05-23 at 10:09 -0700, Tim Hartrick wrote: > > Bob, > > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > > > > Part of me is starting to think that we might be better off waiting for > > there to be more operational experience with deployments of DHCPv6 to see > > how much confusion there really is. I agree it is good for vendors to > > implement similar knobs, but I wonder how much of a problem there really is. > > > > More than part of me is thinking this. It seems to me that there is a > continuing confusion about how these bits interact with local decisions > by the administrator of a specific machine or network. People are > asking questions like "What happens if the M and/or O bits are clear but > there is a DHCP server?" or "What happens if the M and/or O bits are > clear but the client wants to use DHCP anyway" or "What happens if the M > and/or O bits are set and the client doesn't want to run DHCP". None of > these questions are in the realm of protocol design. Clearly, local > administrators will do as they please with their machines. In this > respect the M and O bits have never been anything but strong hints as to > what the client should do. The client is always free to ignore the > hints. Further network administrators are free to misconfigure their > networks as they please. The current text describing these bits is > clear almost to the point of being infantile. This isn't an indictment > of the authors. Rather it is an indictment of attempts to enforce > system configuration and management rules via protocol specifications. > This is impossible. We should stop trying. > > > > > tim > > > -------------------------------------------------------------------- > 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 May 23 14:49:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHzz-0001VN-S5; Mon, 23 May 2005 14:49:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaHzx-0001Tt-RB; Mon, 23 May 2005 14:49:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26888; Mon, 23 May 2005 14:49:56 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIHy-0008LM-MI; Mon, 23 May 2005 15:08:35 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 May 2005 14:49:48 -0400 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 j4NInXlC015561; Mon, 23 May 2005 14:49:45 -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); Mon, 23 May 2005 14:49:31 -0400 Received: from 10.86.242.29 ([10.86.242.29]) 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 ; Mon, 23 May 2005 18:49:31 +0000 Received: from localhost.localdomain by email.cisco.com; 23 May 2005 14:49:56 -0400 From: Ralph Droms To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050523093529.0282cd70@mailhost.iprg.nokia.com> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <6.2.1.2.2.20050523093529.0282cd70@mailhost.iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2005 14:49:55 -0400 Message-Id: <1116874195.5397.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 23 May 2005 18:49:31.0990 (UTC) FILETIME=[280BFF60:01C55FC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Bob - we ought to see what other standards bodies (for example, CableLabs) identify as address assignment requirements and design as IPv6 deployment architectures. - Ralph On Mon, 2005-05-23 at 09:48 -0700, Bob Hinden wrote: > Part of me is starting to think that we might be better off waiting for > there to be more operational experience with deployments of DHCPv6 to see > how much confusion there really is. I agree it is good for vendors to > implement similar knobs, but I wonder how much of a problem there really is. > > Bob > > > > > -------------------------------------------------------------------- > 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 May 23 14:55:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaI4x-0002nV-Te; Mon, 23 May 2005 14:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaI4u-0002mS-R9; Mon, 23 May 2005 14:55:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27602; Mon, 23 May 2005 14:55:03 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIMv-00009I-Ee; Mon, 23 May 2005 15:13:42 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 May 2005 14:54:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2005 14:53:46 -0400 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVfyB8xw8gNFS4WQhiWgKmvdj5E3AAAJe6Q From: "Soliman, Hesham" To: "Ralph Droms" , X-OriginalArrivalTime: 23 May 2005 18:54:52.0645 (UTC) FILETIME=[E72C1150:01C55FC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Make that 200 %. Hesham > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On=20 > Behalf Of > Ralph Droms > Sent: Monday, May 23, 2005 2:47 PM > To: tim@mentat.com > Cc: dhcwg@ietf.org; Bob Hinden; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 >=20 > Tim - I agree 100% with your message. >=20 > - Ralph >=20 > On Mon, 2005-05-23 at 10:09 -0700, Tim Hartrick wrote: > >=20 > > Bob, > >=20 > > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > > >=20 > > > Part of me is starting to think that we might be better=20 > off waiting for=20 > > > there to be more operational experience with deployments=20 > of DHCPv6 to see=20 > > > how much confusion there really is. I agree it is good=20 > for vendors to=20 > > > implement similar knobs, but I wonder how much of a=20 > problem there really is. > > >=20 > >=20 > > More than part of me is thinking this. It seems to me=20 > that there is a > > continuing confusion about how these bits interact with=20 > local decisions > > by the administrator of a specific machine or network. People are > > asking questions like "What happens if the M and/or O bits=20 > are clear but > > there is a DHCP server?" or "What happens if the M and/or=20 > O bits are > > clear but the client wants to use DHCP anyway" or "What=20 > happens if the M > > and/or O bits are set and the client doesn't want to run=20 > DHCP". None of > > these questions are in the realm of protocol design. =20 > Clearly, local > > administrators will do as they please with their machines. In this > > respect the M and O bits have never been anything but=20 > strong hints as to > > what the client should do. The client is always free to ignore the > > hints. Further network administrators are free to=20 > misconfigure their > > networks as they please. The current text describing these bits is > > clear almost to the point of being infantile. This isn't=20 > an indictment > > of the authors. Rather it is an indictment of attempts to enforce > > system configuration and management rules via protocol=20 > specifications.=20 > > This is impossible. We should stop trying. > >=20 > >=20 > >=20 > >=20 > > tim > >=20 > >=20 > >=20 > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests:=20 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 -------------------------------------------------------------------- =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 Mon May 23 15:16:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIPV-0006QA-UF; Mon, 23 May 2005 15:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIPT-0006PW-VE; Mon, 23 May 2005 15:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00351; Mon, 23 May 2005 15:16:18 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIhV-0000vO-T4; Mon, 23 May 2005 15:34:58 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id AE3DF20000DF; Mon, 23 May 2005 15:16:06 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:16:06 -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: Mon, 23 May 2005 15:16:03 -0400 Message-ID: <936A4045C332714F975800409DE092404A08DD@tayexc14.americas.cpqcorp.net> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVft50DzN4ETYLkQsSSw22UvrCK7QAE/bcg From: "Bound, Jim" To: "Bob Hinden" , "Pekka Savola" X-OriginalArrivalTime: 23 May 2005 19:16:06.0607 (UTC) FILETIME=[DE833DF0:01C55FCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Bob, THere is no problem. The site owns the router configuration and the network admins are gods of rules. If the site sets the m bit the client is told go look for dhcpv6. if not set don't bother. If o set go look for configs. Pretty simple and I suspect people are looking for away to avoid clients obeying the mandate from the router and the site. We should not support that at all or work on it. The rules are clear. thanks /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bob Hinden > Sent: Monday, May 23, 2005 12:49 PM > To: Pekka Savola > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt=20 >=20 > Pekka, >=20 > >Actually, the lack of M or O bits is not as good a hint as their=20 > >existence. If we wanted a _good_ hint about non-existence=20 > of DHCPv6 (for=20 > >addresses or config information), we'd have to have=20 > different flag(s) like=20 > >"Yes, I'm aware of what DHCPv6 is, but we don't use it in this=20 > >network". That allows disambiguation from "Yes, we do have=20 > a couple of=20 > >DHCPv6 servers, but we weren't aware you should configure=20 > this stuff in=20 > >the RAs, because with v4 you don't". >=20 > This still seems to be to be fairly equivalent. I think the=20 > important=20 > function is if there is a DHCPv6 server and the site want the=20 > clients to=20 > use it, then they should set the "m" and "o" bits. I don't=20 > see very much=20 > value in conveying the negatives (e.g., we have a DHCPv6=20 > server, but we=20 > don't want the clients to use it, we don't have a DHCPv6=20 > server so don't=20 > try looking for one, we didn't set up a relay, etc., etc.). >=20 > >But I'm not sure that disambiguation is worth the effort. >=20 > Agreed. >=20 > >That said, I support the clarification. In a sense I agree=20 > with Thomas et=20 > >al that the ra-mo-flags spec goes beyond the bare minimum=20 > what the IETF=20 > >specifications must specify -- it documents the policies and=20 > behaviours=20 > >which most vendors would implement in any case, but these=20 > kind of knobs=20 > >have often been left out of our specs. However, as there=20 > has been so much=20 > >confusion and discussion of M/O flags, I think this specification is=20 > >useful, and also allows vendors (who want to) to implement=20 > the knobs in a=20 > >uniform manner. >=20 > Part of me is starting to think that we might be better off=20 > waiting for=20 > there to be more operational experience with deployments of=20 > DHCPv6 to see=20 > how much confusion there really is. I agree it is good for=20 > vendors to=20 > implement similar knobs, but I wonder how much of a problem=20 > there really is. >=20 > Bob >=20 >=20 >=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 Mon May 23 15:18:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIRO-0006ZI-3E; Mon, 23 May 2005 15:18:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIRM-0006Yl-Bx; Mon, 23 May 2005 15:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00574; Mon, 23 May 2005 15:18:15 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaIjO-0000y0-Jq; Mon, 23 May 2005 15:36:54 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 7F95920000D6; Mon, 23 May 2005 15:18:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 15:18:07 -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: Mon, 23 May 2005 15:18:05 -0400 Message-ID: <936A4045C332714F975800409DE092404A08E1@tayexc14.americas.cpqcorp.net> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVfuy4qRU9Vj5YgQFecJ1BDntB07wAEM1cg From: "Bound, Jim" To: , "Bob Hinden" X-OriginalArrivalTime: 23 May 2005 19:18:07.0399 (UTC) FILETIME=[2682A370:01C55FCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 Well stated and with this can we please stop there is no other point to discuss. For those that don't like stateful don't use it. For those that don't like stateless your stuck with it by default set the m and/or o bits. =20 thanks /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Tim Hartrick > Sent: Monday, May 23, 2005 1:09 PM > To: Bob Hinden > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt >=20 >=20 >=20 > Bob, >=20 > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote: > >=20 > > Part of me is starting to think that we might be better off=20 > waiting for=20 > > there to be more operational experience with deployments of=20 > DHCPv6 to see=20 > > how much confusion there really is. I agree it is good for=20 > vendors to=20 > > implement similar knobs, but I wonder how much of a problem=20 > there really is. > >=20 >=20 > More than part of me is thinking this. It seems to me that there is a > continuing confusion about how these bits interact with local=20 > decisions > by the administrator of a specific machine or network. People are > asking questions like "What happens if the M and/or O bits=20 > are clear but > there is a DHCP server?" or "What happens if the M and/or O bits are > clear but the client wants to use DHCP anyway" or "What=20 > happens if the M > and/or O bits are set and the client doesn't want to run=20 > DHCP". None of > these questions are in the realm of protocol design. Clearly, local > administrators will do as they please with their machines. In this > respect the M and O bits have never been anything but strong=20 > hints as to > what the client should do. The client is always free to ignore the > hints. Further network administrators are free to misconfigure their > networks as they please. The current text describing these bits is > clear almost to the point of being infantile. This isn't an=20 > indictment > of the authors. Rather it is an indictment of attempts to enforce > system configuration and management rules via protocol=20 > specifications.=20 > This is impossible. We should stop trying. >=20 >=20 >=20 >=20 > tim >=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 Mon May 23 15:42:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIoz-0002Jk-NB; Mon, 23 May 2005 15:42:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIov-0002Iw-4b; Mon, 23 May 2005 15:42:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02761; Mon, 23 May 2005 15:42:35 -0400 (EDT) Message-Id: <200505231942.PAA02761@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 23 May 2005 15:42:35 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-ndproxy-02.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-02.txt Pages : 20 Date : 2005-5-23 Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. The behavior of one common type of IPv4 ARP Proxy deployed today is documented herein for informational purposes, but this document concentrates on describing similar behavior for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ndproxy-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ndproxy-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-23144936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ndproxy-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ndproxy-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-23144936.I-D@ietf.org> --OtherAccess-- --NextPart 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 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon May 23 15:42:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIpF-0002Kt-L7; Mon, 23 May 2005 15:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaIpC-0002KH-As; Mon, 23 May 2005 15:42:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02775; Mon, 23 May 2005 15:42:52 -0400 (EDT) Message-Id: <200505231942.PAA02775@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 23 May 2005 15:42:52 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-addr-arch-v4-04.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-addr-arch-v4-04.txt Pages : 25 Date : 2005-5-23 This specification defines the addressing architecture of the IP Version 6 protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-3513 "IP Version 6 Addressing Architecture". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-addr-arch-v4-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-23144942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-addr-arch-v4-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-addr-arch-v4-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-23144942.I-D@ietf.org> --OtherAccess-- --NextPart 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 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Mon May 23 17:22:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKNr-0004gG-L1; Mon, 23 May 2005 17:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaKNp-0004fg-QA; Mon, 23 May 2005 17:22:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22875; Mon, 23 May 2005 17:22:43 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKfr-0001n5-O6; Mon, 23 May 2005 17:41:25 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:944:afb5:594e:4c2d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 124C915218; Tue, 24 May 2005 06:25:00 +0900 (JST) Date: Tue, 24 May 2005 06:23:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com In-Reply-To: <1116868160.22946.13.camel@feller> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <1116868160.22946.13.camel@feller> 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: b7b9551d71acde901886cc48bfc088a6 Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 23 May 2005 10:09:20 -0700, >>>>> Tim Hartrick said: >> Part of me is starting to think that we might be better off waiting for >> there to be more operational experience with deployments of DHCPv6 to see >> how much confusion there really is. I agree it is good for vendors to >> implement similar knobs, but I wonder how much of a problem there really is. > More than part of me is thinking this. It seems to me that there is a > continuing confusion about how these bits interact with local decisions > by the administrator of a specific machine or network. People are > asking questions like "What happens if the M and/or O bits are clear but > there is a DHCP server?" or "What happens if the M and/or O bits are > clear but the client wants to use DHCP anyway" or "What happens if the M > and/or O bits are set and the client doesn't want to run DHCP". None of > these questions are in the realm of protocol design. Clearly, local > administrators will do as they please with their machines. In this > respect the M and O bits have never been anything but strong hints as to > what the client should do. The client is always free to ignore the > hints. Further network administrators are free to misconfigure their > networks as they please. The current text describing these bits is > clear almost to the point of being infantile. This isn't an indictment > of the authors. Rather it is an indictment of attempts to enforce > system configuration and management rules via protocol specifications. > This is impossible. We should stop trying. First of all, as a part of the authors of the "infantile" document, I'd like to emphasize once again that it's not our goal to *enforce* system configuration issues through a protocol document. Perhaps the current text is overacting, but the goal is to "clarify" (as the title of the document shows) confusing points about the M/O flags. (You seem to agree that there *is* confusion, but are saying that clarifying those points is not IETF's work, correct?) Anyway, regarding Bob's point, I can live with that. In fact, my position of these bits has always been we don't have much experience with these flags to be more specific about their usage. And that's why I hesitated to describe more details about those flags in rfc2462bis. On top of this fact, I can live with the approach of leaving the current confusion as is and waiting until we get enough operational experience (then we may or may not need a separate document). Before actually taking this approach, however, I'd like to make a couple of additional notes beforehand: - we removed from rfc2462bis some statements regarding the M/O flags and the "stateful" protocol (=DHCPv6), such as this one: If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. or one even with an RFC2119 keyword: In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating with the intention of clarifying these points in the ipv6-ra-mo-flags document. If we stop this work, it means these statements will simply disappear. - rfc2461bis will also need to remove the last sentence from the description of the M/O flags: M 1-bit "Managed address configuration" flag. When set, it indicates that Dynamic Host Configuration Protocol [DHCPv6] is available for address configuration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is further described in [ADDRCONF]. (this comment already applies regardless of the future of ra-mo-flags, since [ADDRCONF](=rfc2462bis) does not talk about these flags anymore) 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 Mon May 23 18:42:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLce-00015u-IY; Mon, 23 May 2005 18:42:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLcd-00012p-KO; Mon, 23 May 2005 18:42:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07372; Mon, 23 May 2005 18:42:04 -0400 (EDT) Received: from mentat.com ([192.88.122.129] helo=roll.mentat.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLuh-00072y-59; Mon, 23 May 2005 19:00:47 -0400 Received: from alerion.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.7p1+Sun/8.11.7+Mentat) with ESMTP id j4NMftp22349; Mon, 23 May 2005 15:41:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id 8EE763F0021; Mon, 23 May 2005 15:41:55 -0700 (PDT) Received: from alerion.mentat.com ([127.0.0.1]) by localhost (alerion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21114-03; Mon, 23 May 2005 15:41:54 -0700 (PDT) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id 77B573F0020; Mon, 23 May 2005 15:41:54 -0700 (PDT) From: Tim Hartrick To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: <57482c02880cda3a9a5e541bb72ca6fc@message.md5> References: <200505201747.j4KHlPAm022320@rotala.raleigh.ibm.com> <6.2.1.2.2.20050520155825.0304a748@mailhost.iprg.nokia.com> <1116868160.22946.13.camel@feller> <57482c02880cda3a9a5e541bb72ca6fc@message.md5> Content-Type: text/plain; charset=UTF-8 Organization: Mentat Inc. Message-Id: <1116887762.22946.43.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 May 2005 15:36:02 -0700 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roll.mentat.com id j4NMftp22349 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Bob Hinden , ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@mentat.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 Jinmei, On Mon, 2005-05-23 at 14:23, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: >=20 > > More than part of me is thinking this. It seems to me that there is = a > > continuing confusion about how these bits interact with local decisio= ns > > by the administrator of a specific machine or network. People are > > asking questions like "What happens if the M and/or O bits are clear = but > > there is a DHCP server?" or "What happens if the M and/or O bits are > > clear but the client wants to use DHCP anyway" or "What happens if th= e M > > and/or O bits are set and the client doesn't want to run DHCP". None= of > > these questions are in the realm of protocol design. Clearly, local > > administrators will do as they please with their machines. In this > > respect the M and O bits have never been anything but strong hints as= to > > what the client should do. The client is always free to ignore the > > hints. Further network administrators are free to misconfigure their > > networks as they please. The current text describing these bits is > > clear almost to the point of being infantile. This isn't an indictme= nt > > of the authors. Rather it is an indictment of attempts to enforce > > system configuration and management rules via protocol specifications= .=20 > > This is impossible. We should stop trying. >=20 > First of all, as a part of the authors of the "infantile" document, > I'd like to emphasize once again that it's not our goal to *enforce* > system configuration issues through a protocol document. Perhaps the > current text is overacting, but the goal is to "clarify" (as the title > of the document shows) confusing points about the M/O flags. (You > seem to agree that there *is* confusion, but are saying that > clarifying those points is not IETF's work, correct?) >=20 I made it clear that the current text is, I believe, a reaction on the authors' part to the persistent attempts to place operational restrictions on this protocol mechanism from within the specification.=20 The clarity is good. I am for clarity. I apologize for any offense.=20 However, I am against continuing to modify the document and the protocol in the hopes that the questions cited above will cease. They won't because they have nothing to do with the protocol. They have to do with operators wanting to tell users how to use their machines and users not wanting to do what operators want them to do and how that tension gets sorted out by what features and knobs are included or not included in the implementations the operators and users purchase. We aren't writing product specifications here. Trying to specify every implementation knob in the protocol specification is a mistake and removing useful features because all the possible knobs to control it aren't specified is also a mistake. tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 23 21:28:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaOE2-0007jH-MM; Mon, 23 May 2005 21:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaODy-0007ic-Ju; Mon, 23 May 2005 21:28:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20937; Mon, 23 May 2005 21:28:48 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaOW3-0004rH-FJ; Mon, 23 May 2005 21:47:31 -0400 Received: from ep_mmp1 (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 <0IGZ006I703EDO@mailout1.samsung.com>; Tue, 24 May 2005 10:28:26 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IGZ0072T03E36@mmp1.samsung.com>; Tue, 24 May 2005 10:28:26 +0900 (KST) Date: Tue, 24 May 2005 10:28:22 +0900 From: "Soohong Daniel Park@SAMSUNG.COM" In-reply-to: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> To: "'Thomas Narten'" , ipv6@ietf.org Message-id: <019201c55fff$df84d1d0$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org Subject: RE: meta thoughts on m/o bits 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 too late response) I am really not sure why this thread is moved to *meta thought*. When I wrote this document, I originally thought this task was our explicit consensus to be a seperated document from 2462bis. Am I missing anything ? I don't think so. See below link (October 2004) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03799.html It would have been nice if you said your comment at that time. As you mentiond, simplicity is also good aspect and we (all author) was trying to make this document as simple as we can. If we feel it so heavy, we will make it more concise than now. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of Thomas Narten > Sent: Saturday, May 21, 2005 2:24 AM > To: ipv6@ietf.org > Subject: meta thoughts on m/o bits > > > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... > > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. > > In an ideal world, there would be exactly one way for a client to > invoke DHC. That is, it would use the same message exchange to get > "addresses" as it did for "non-address configuration". In such a > world, there would be no need for the M/O bits, since the client would > do the same thing if either one of them were set. > > Unfortunately, we are not quite there, since DHC actually has HCB & > ICB message exchanges (using Ralph's terminology). Thus, there are > scenarios where invoking ICB is preferable over HCB. (Aside note: here > is another example where having two ways to do similar things, results > in undesirable complexity). Currently, we sort of need the M/O bits so > a client can know which variant of DHC to invoke. But, we now also > allow for the possibility of "silly states", i.e., states that aren't > supposed to happen, but can, e.g., through misconfiguration. Having > the M bit set but no addresses available is one such example. > > Ralph has already indicated that with some small changes to the DHC > spec, we might be able to fix the DHC issue so that there is one way > to invoke DHC that does the right thing in all combinations of > addresses and/or other configuration information being available via > DHC. > > If we had that, we wouldn't need two RA bits anymore. At most, a > single "there is stuff to obtain via DHC" bit would suffice. > > Indeed, one could go further and say "just always invoke DHC", and > don't even bother with an RA bit saying DHC is available. That has the > nice property of being simple to implement and you don't have silly > states where the RA bit(s) are configured incorrectly, etc. > > The only advantage I can see right off to having at least 1 RA bit is > to tell the client "there is no DHC server running, so don't even > bother". This would be a performance optimization to allow one to > avoid needing to invoke DHC and have it timeout -- before concluding > that there are no DHC servers. Is this a significant optimization? > Hard to say. > > What I would like to suggest: followup on the above proposed DHC > changes and see if we can actually "fix" DHC to simplify what the > client has to do to invoke it. And if that works, do away with one or > both of the RA bits. > > Remember, simplicity is Good! > > Thomas > > -------------------------------------------------------------------- > 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 May 24 07:40:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaXmD-0004fJ-Fx; Tue, 24 May 2005 07:40:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaXmB-0004fE-PC for ipv6@megatron.ietf.org; Tue, 24 May 2005 07:40:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19127 for ; Tue, 24 May 2005 07:40:46 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaY4L-0007eJ-Pp for ipv6@ietf.org; Tue, 24 May 2005 07:59:35 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.12059386; Tue, 24 May 2005 07:40:05 -0400 Mime-Version: 1.0 (Apple Message framework v622) To: IPv6 WG Message-Id: <8c036d2bf506cf369f56477701e54db8@innovationslab.net> From: Brian Haberman Date: Tue, 24 May 2005 07:40:03 -0400 X-Mailer: Apple Mail (2.622) X-esp: ESP<41>=RBL:<0> RDNS:<0> SHA:<41> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> HTML Dictionary (TRU6):<0> NigeriaScam Dictionary (TRU6):<0> URL Dictionary (TRU6):<0> Phishing:<0> Spam Dictionary (TRU6):<0> CAN-SPAM Compliance Dictionary (TRU6):<0> Obscenities Dictionary (TRU6):<0> Embed HTML Dictionary (TRU6):<0> Porn Dictionary (TRU6):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Bob Hinden Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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="===============0126597646==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0126597646== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--958833279; protocol="application/pkcs7-signature" --Apple-Mail-1--958833279 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit IPv6 WG, This begins a 1-week Working Group Last Call on advancing: Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-02.txt Pages : 20 Date : 2005-5-23 as an Informational document. Substantive comments should be directed to the mailing list. Minor comments and editorial issues can be sent to the editor. This last call will end on June 3, 2005. We also request that people comment on their support or opposition to advancing this document. There has been mixed public support for this work and it cannot advance without consensus from the working group. Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-1--958833279 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNTI0MTE0MDA0WjAjBgkqhkiG9w0B CQQxFgQU4mbN2kkjOC281DGR6oze/HDAObMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAHmSHYUR3xN457eqNPedheFmhkyMA5Y8P5CT5EBomEQWS/VoIF4v/QVwgjdMGbITQ8k5Q 2HRToq7Sge26lqt9x5Iq7teruhsCFl2ixCOwEvxHDv6oSNgraaHK4/w4/BgpqE2/8TkKhlrO2dWF HRkOXSGFWBeH7J4L4Fc6SndEO/XIxWks/bjPZ15UnaBro6wLiLPn/Bl8eqZ5tMtygmZisIWY0aqr gzAlFaeFwJ3zYbGn0diYi6qn+i2fUH7TgdqP3g8XIgbf5BABvwPT7y/T0Q9IEkwW11Y4uc+hho4J ++GYRoVphEdd6o9idThAUKPx7pF95EB8lwRJ2uI5+1+GGQAAAAAAAA== --Apple-Mail-1--958833279-- --===============0126597646== 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 -------------------------------------------------------------------- --===============0126597646==-- From ipv6-bounces@ietf.org Tue May 24 08:00:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaY53-0007nV-2m; Tue, 24 May 2005 08:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaY4y-0007n9-NB for ipv6@megatron.ietf.org; Tue, 24 May 2005 08:00:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21018 for ; Tue, 24 May 2005 08:00:11 -0400 (EDT) From: juha.wiljakka@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaYN8-00007i-M9 for ipv6@ietf.org; Tue, 24 May 2005 08:19:00 -0400 Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4OC06MB020510; Tue, 24 May 2005 15:00:08 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 15:00:07 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 15:00:07 +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, 24 May 2005 15:00:06 +0300 Message-ID: <7FC6DDC5C9490F4C9657B8ABC14B7A83B78E2D@esebe106.NOE.Nokia.com> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt Thread-Index: AcVgVfafg4Pg7Du5Q3ecxUEkuF2W+gAAWHoA To: X-OriginalArrivalTime: 24 May 2005 12:00:07.0193 (UTC) FILETIME=[20B33090:01C56058] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: brian@innovationslab.net, Bob.Hinden@nokia.com Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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, I warmly support moving forward with this document as this is useful = piece of work. I don't have bigger issues with the current draft.=20 BR, -Juha W.- -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of ext Brian Haberman Sent: 24 May, 2005 14:40 To: IPv6 WG Cc: Hinden Bob (Nokia-ES/MtView) Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt IPv6 WG, This begins a 1-week Working Group Last Call on advancing: Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-02.txt Pages : 20 Date : 2005-5-23 as an Informational document. Substantive comments should be directed to the mailing list. Minor comments and editorial issues can be sent to the editor. This last call will end on June 3, 2005. We also request that people comment on their support or opposition to advancing this document. There has been mixed public support for this work and it cannot advance without consensus from the working group. Regards, Brian & Bob IPv6 WG co-chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 24 09: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 1DaZ6W-0001qm-RM; Tue, 24 May 2005 09: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 1DaZ6S-0001qe-Hr for ipv6@megatron.ietf.org; Tue, 24 May 2005 09:05:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27516 for ; Tue, 24 May 2005 09:05:47 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaZOe-0002WU-5w for ipv6@ietf.org; Tue, 24 May 2005 09:24:36 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 375014; Tue, 24 May 2005 09:01:23 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8c036d2bf506cf369f56477701e54db8@innovationslab.net> References: <8c036d2bf506cf369f56477701e54db8@innovationslab.net> Date: Tue, 24 May 2005 09:04:09 -0400 To: Brian Haberman , IPv6 WG From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Thomas Narten , Bob Hinden Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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 have a process-related concern with draft-ietf-ipv6-ndproxy-02.txt that I would like to discuss on this list to see what others think... I haven't reached the point (yet) where I have a fully-formed objection, but I have a strong enough concern that I thought it would be worth some discussion before the IPv6 WG sends this document to the IESG. This concern is entirely separate from any technical concerns that may arise when I do another full technical review of the document. This document is proposed to address the following charter item: - Develop Proxy Neighbor Discovery solution for prefix delegation and publish. This enables a simple site border router to re-advertise downstream a prefix it hears on its upstream link. However, it is clear that the document itself -- which proposes a multi-link, bridge replacement mechanism using RSTP and IPv6 encapsulation, goes well beyond what is required to address the charter item. When we agreed to include this charter item (I was an IPv6 WG chair at the time), I had expected a substantially trimmed-down version of ND Proxy that would only include the "P-bit" mechanism for single-step prefix delegation. Could the current chairs perhaps comment on how they believe that the ND Proxy document, as it currently exists, fits within the IPv6 WG charter? Is there anyone else who has an opinion on this? This is not merely a legalistic concern. I am concerned that the people who should be involved in the standardization an RSTP-based L3 bridging technology may not be involved in the IPv6 WG. In fact, they may not even be aware that this work is underway here. Therefore, this document may not have been developed and reviewed by a group that has the balance of experience needed to reach valid IETF consensus on this work. Thoughts? Margaret At 7:40 AM -0400 5/24/05, Brian Haberman wrote: >Content-Type: multipart/signed; micalg=sha1; >boundary="=_reb-r561C5807-t4293136D"; > protocol="application/pkcs7-signature" > >IPv6 WG, > This begins a 1-week Working Group Last Call on advancing: > > Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) > Author(s) : D. Thaler, et al. > Filename : draft-ietf-ipv6-ndproxy-02.txt > Pages : 20 > Date : 2005-5-23 > >as an Informational document. Substantive comments should be >directed to the mailing list. Minor comments and editorial issues can >be sent to the editor. This last call will end on June 3, 2005. > >We also request that people comment on their support or opposition >to advancing this document. There has been mixed public support for >this work and it cannot advance without consensus from the working >group. > >Regards, >Brian & Bob >IPv6 WG co-chairs > >Attachment converted: Macintosh HD:smime 463.p7s ( / ) (0017E4FA) >-------------------------------------------------------------------- >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 May 24 10:05:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daa2Y-0003Ky-N3; Tue, 24 May 2005 10:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daa2X-0003Kt-5f for ipv6@megatron.ietf.org; Tue, 24 May 2005 10:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02130 for ; Tue, 24 May 2005 10:05:47 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaaKi-0004V1-Dm for ipv6@ietf.org; Tue, 24 May 2005 10:24:37 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 May 2005 10:05:38 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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, 24 May 2005 10:04:25 -0400 Message-ID: Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt Thread-Index: AcVfyB8xw8gNFS4WQhiWgKmvdj5E3AAoQiaQ From: "Soliman, Hesham" To: X-OriginalArrivalTime: 24 May 2005 14:05:38.0320 (UTC) FILETIME=[A999F900:01C56069] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Subject: 2461bis update 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 submitted an updated revision of 2461bis which includes=20 the resolutions that were agreed on by the WG in the last meeting (the SLLAO thread). It also includes fixes for the comments Tatuya raised on the last version.=20 I think this draft is now ready for the IESG.=20 Thanks, Hesham =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 Tue May 24 10:45:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daaf0-0001BH-NS; Tue, 24 May 2005 10:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daaez-0001BB-BJ for ipv6@megatron.ietf.org; Tue, 24 May 2005 10:45:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06141 for ; Tue, 24 May 2005 10:45:29 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daax8-0005lb-LL for ipv6@ietf.org; Tue, 24 May 2005 11:04:20 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4OEjKcE382368 for ; Tue, 24 May 2005 10:45:20 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEjKuc225978 for ; Tue, 24 May 2005 08:45:20 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4OEjKUq018032 for ; Tue, 24 May 2005 08:45:20 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEjJPm018005 for ; Tue, 24 May 2005 08:45:19 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4OEjJST025427 for ; Tue, 24 May 2005 10:45:19 -0400 Message-Id: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> To: ipv6@ietf.org In-Reply-To: Message from Thomas Narten of "Fri, 20 May 2005 13:24:26 EDT." <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> Date: Tue, 24 May 2005 10:45:19 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: purpose of m/o bit 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 wonder if there is key question here that the community has simply not agreed on (yet), and that that question is at the heart of all this "confusion". Does the community feel that operators need RA bits that control/indicate whether a client is to invoke DHC? That is, is there a need for the sys admin to signal to client whether DHC is to be invoked? Second, is it important that such a signal be honored by clients? (That is, if clients end up mostly ignoring the flags, does their presence become useless?) For example, should the sys admin be able to say "do not run DHC, doing so wastes local resources and won't get you any config info"? (And should that be honored by clients?) Fundamentally, it is only the access network that has knowledge of whether running DHC is useful. Thus, by default, clients (arguably) can't know whether running DHC is useful, so by default they shold invoke DHC (unless the sys admin signals "don't invoke DHC"). Or (switching the argument), by default, client should not invoke DHC, unless the local sys admin indicates doing so is appropriate. If we can't agree that the above is necessary (i.e., is a "problem statement" of sorts), I really have to wonder what purpose the R/A bits can serve or whether we will ever have a shared understanding of what they are supposed to do. Having them be a hint (that clients in practice ignore half the time) would seem to solve no useful purpose (IMO) and would provide the sys admin with useless tools (since clients wouldn't respond to the usage of the tool in predicatable ways). The result would simply be more confusion. (Oh, that is already the state we are in!!! :-)) So, what is it? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 24 10:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daafl-0001EM-Vs; Tue, 24 May 2005 10:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daafk-0001EE-K3; Tue, 24 May 2005 10:46:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06172; Tue, 24 May 2005 10:46:18 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daaxw-0005qP-6O; Tue, 24 May 2005 11:05:09 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEk8gi007137; Tue, 24 May 2005 10:46:08 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEk7Lu144284; Tue, 24 May 2005 10:46:07 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4OEk77U000444; Tue, 24 May 2005 10:46:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEk7rx000404; Tue, 24 May 2005 10:46:07 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4OEk6WR025434; Tue, 24 May 2005 10:46:06 -0400 Message-Id: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Sat, 14 May 2005 17:35:37 +0900." Date: Tue, 24 May 2005 10:46:06 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: dhcwg@ietf.org, IPv6 WG Subject: Original intent of M/O bits [was Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.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 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > If we respect both the original sense of RFC2462 and our consensus > about the semantics separation of the M/O flags, I believe the right > solution is the following: I think we should be careful NOT to get hung up on what the original intent of the M/O bits were, but focus on what the right behavior should be, given what we know now/today, and given the DHC protocols we actually have. The M/O bits were defined before we had DHCPv6 specified. I'd argue that the M/O bits are a classic example of defining protocol/bits before we really had a clear understanding of how they would be used, what the semantics should be or what the actual protocols would be that get invoked as a result of those bits. Surprise, surprise, when one invents protocols/mechanisms in such cases, we often get the details wrong. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 24 10:53:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daan5-0002ai-5b; Tue, 24 May 2005 10:53:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daan2-0002Ub-Rv for ipv6@megatron.ietf.org; Tue, 24 May 2005 10:53:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06990 for ; Tue, 24 May 2005 10:53:50 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dab5F-0006AX-6c for ipv6@ietf.org; Tue, 24 May 2005 11:12:41 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 5EB222000366; Tue, 24 May 2005 10:48:29 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:44:39 -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, 24 May 2005 10:44:37 -0400 Message-ID: <936A4045C332714F975800409DE092404A0B57@tayexc14.americas.cpqcorp.net> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt Thread-Index: AcVgVlzLHwiRqNtwSLKAwi4zeSv/pAAFK2hw From: "Bound, Jim" To: "Brian Haberman" , "IPv6 WG" X-OriginalArrivalTime: 24 May 2005 14:44:39.0446 (UTC) FILETIME=[1D057360:01C5606F] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: Bob Hinden Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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 Brian and authors, My response below. Thus I cannot support this going to the IESG without further discussion as my input. I also support Margaret's request for this to be checked by RTSP persons, and I realize Dave T. clearly has this expertise but it is a good logic check. Unless we want to remove RSTP. I think we should include RSTP but it needs more review. General Comments: I also would like to see this work not focus at all on IPv4 and only address IPv6. The IPv4 work should be a separate document completely. To permit this behavior for prefixes to span links in IPv6 is a significant change to one of our architectural precepts for IPv6 and cannot be considered lightly, regarding link behavior.=20 Because it is an informational document I do not ask for implementation but it would be good to suggest this somewhere in the spec. If it were going to PS then implementation in this case is example where I think the IETF has to ask for that as it could negatively impact current and future deployment of IPv6. I would like to see a third scenario that aligns better with section 4. The two presented are ok but depicting two links with proxy between as in section 4 would be good scenario to add. I think DHCPv6 needs to be addressed when in use by the client and is missing in the discussion. Specific comments below: From=20 >3.1. Non-requirements >The following items are not considered requirements, as they are >not met by classic bridges: > The following additional items are not considered requirements for > this document: >o Support Neighbor Discovery, Router Discovery, or DHCPv4 > packets using IPsec. We also note that the current methods > for securing these protocols do not use IPsec so this is > considered acceptable. That IPsec will not be used or is not being used for ND is simply not valid or true. This may be an opinion or state for deployment by the authors but it is certainly not the view of all regarding deployment. Thus IPsec must be addressed if it is used and a statement what this means to the ndproxy proposal. I feel this is a hard requirement. This shows up again below as issue for me indirectly. From >4. Bridge-Like Proxy Behavior >As with all other interfaces, IPv4 and IPv6 maintain a neighbor >cache (aka "ARP cache") for each proxy interface, which will be >used as described below. For readability, we will describe the >neighbor cache as if both IPv4 and IPv6 neighbors use the same >state machine described in [ND]. That is not good to state IPv4 can use same abstraction as ND and gives the wrong impression to a reader. It simply is not true for most implementations. But, I would like IPv4 removed from this spec. The ND spec clearly documents the diffs and they are great enough to even compare or identify in this manner is not prudent in a specification. >4.1.3.3. DHCPv4 Packets Need section on DHCPv6. >4.1.4.3. ICMPv6 Router Advertisements >If an RA with the P bit set has arrived on a given interface >(including the upstream interface) within the last 60 minutes, >that interface MUST NOT be used as a proxy interface; i.e., proxy >functionality is disabled on that interface. The Proxy is acting as a router and this requirement for a P bit does affect router implementations and that was a non goal. This is a discrepancy and if the Proxy is a router it needs to adhere to that which a router must do and that needs to be added to the spec somewhere. >4.2. Originating Packets >P receives the solicitation (since it is receiving all link-layer >multicast packets) and processes it as it would any multicast >packet by forwarding it out to other segments on the link. >However, before actually sending the packet, it determines if the >packet being sent is one which requires proxying. Since it is an >NS, it creates a neighbor entry for A on interface 1 and records >its link-layer address. It also creates a neighbor entry for B >(on an arbitrary proxy interface) in the INCOMPLETE state. Since >the packet is multicast, P then needs to proxy the NS out all >other proxy interfaces on the subnet. Before sending the packet >out interface 2, it replaces the link-layer address in the SLLA >option with its own link-layer address, p2. This a routing function though a proxy and do we want to add this function to router requirements. This also has security issues that could cause DOS and affect data integrity of the network configuration parameters. =20 >6. Loop Prevention >Loop prevention using RSTP would typically be done by devices that >already implement this protocol as a result of supporting normal >briding functionality, and is done here as follows. IEEE 802 >interfaces use the protocol exactly as specified in [BRIDGE]. >Operation of RSTP over other types of link layers is done by >encapsulating the RSTP frame in an IPv6 header. The Next Header >field is set to [TBA by IANA], indicating that an RSTP header >follows. The Destination Address field is set to the Link-scoped >RSTP Multicast Group [TBA by IANA]. All proxies operating on non- >IEEE 802 media join this group so they will receive RSTP packets. >RSTP packets are never forwarded or proxied. Now packets are being added for NH and DST options and that needs to be checked if it is the best method to perform this function. It might be better as hop-by-hop option rather than DST option as thought. This should all be checked with RTSP WG in IETF. >Loop avoidance using the P bit in RAs is done as follows. The >proxy determines an "upstream" proxy interface, typically through >a physical choice dictated by the scenario (see Scenarios 1 and 2 >above), or through manual configuration. As described in Section >4.1.3.3, only the upstream interface is allowed to receive RAs, >and never from other proxies. Proxy functionality is disabled on >an interface otherwise. Finally, a proxy MUST wait until it has >sent two P bit RAs on a given "downstream" interface before it >enables forwarding on that interface. We have now used up precious bit space in ND and I do not see the justification unless we open this concept to working with general router implementations and that is what the proxy is in my view. >7. Guidelines to proxy developers This should be appendix not part of the specification. It is conjecture and suggestion that is all. >9. Security Considerations The security section is fair assessment but assuming SEND is not valid and many of us have many issues with SEND including but not limited to IPR, interface with PKIs, and that it does not assist with identification of the node on a wireless network. NDproxy now permits a rogue node to not only attack one link but now multiple links via the Proxy and thus exacerbates the entire problem we have with stateless wireless nodes in general. This needs to be added to the current list of security section. In addition I would like to see a softer support that SEND solves anything and a TBD. thanks /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Brian Haberman > Sent: Tuesday, May 24, 2005 7:40 AM > To: IPv6 WG > Cc: Bob Hinden > Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt >=20 > IPv6 WG, > This begins a 1-week Working Group Last Call on advancing: >=20 > Title : Bridge-like Neighbor Discovery=20 > Proxies (ND Proxy) > Author(s) : D. Thaler, et al. > Filename : draft-ietf-ipv6-ndproxy-02.txt > Pages : 20 > Date : 2005-5-23 >=20 > as an Informational document. Substantive comments should be > directed to the mailing list. Minor comments and editorial issues can > be sent to the editor. This last call will end on June 3, 2005. >=20 > We also request that people comment on their support or opposition > to advancing this document. There has been mixed public support for > this work and it cannot advance without consensus from the working > group. >=20 > Regards, > Brian & Bob > IPv6 WG co-chairs >=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 May 24 11:12:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab58-0007H3-EH; Tue, 24 May 2005 11:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab55-0007GT-IX; Tue, 24 May 2005 11:12:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09045; Tue, 24 May 2005 11:12:29 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DabNI-000746-30; Tue, 24 May 2005 11:31:20 -0400 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel12.hp.com (Postfix) with ESMTP id 8A439411437; Tue, 24 May 2005 08:12:27 -0700 (PDT) Received: from cacexb11.americas.cpqcorp.net ([16.92.1.48]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 08:12:27 -0700 Received: from tayexb11.americas.cpqcorp.net ([16.103.130.93]) by cacexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 08:12:27 -0700 Received: from tayexg11.americas.cpqcorp.net ([16.103.130.186]) by tayexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 11:12:01 -0400 Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 11:08:12 -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="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Tue, 24 May 2005 11:08:11 -0400 Message-ID: <936A4045C332714F975800409DE092404A0B85@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] Original intent of M/O bits [was Re: IPv6 WG LastCall:draft-ietf-ipv6-ra-mo-flags-01.txt ] Thread-Index: AcVgcDTTKGIO+UcnQgSPQoa3waPMcgAAfocQ From: "Bound, Jim" To: "Thomas Narten" , =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-OriginalArrivalTime: 24 May 2005 15:08:12.0766 (UTC) FILETIME=[676CF7E0:01C56072] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IPv6 WG Subject: RE: [dhcwg] Original intent of M/O bits [was Re: IPv6 WG LastCall:draft-ietf-ipv6-ra-mo-flags-01.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 Thomas, With respect. When we defined M and O we were assuming a stateful support system. Thus we did the right thing. I was there as you. Those that are in denial that stateful is as important to the business and market deployment of IPv6 are simply missing the point. In addition, and I think we agree on this point, it is not the IETFs business to tell the market what or how to deploy. /jim > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Thomas Narten > Sent: Tuesday, May 24, 2005 10:46 AM > To: JINMEI Tatuya / $B?@L@C#:H(J > Cc: dhcwg@ietf.org; IPv6 WG > Subject: [dhcwg] Original intent of M/O bits [was Re: IPv6 WG > LastCall:draft-ietf-ipv6-ra-mo-flags-01.txt ] > > JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > writes: > > > If we respect both the original sense of RFC2462 and our consensus > > about the semantics separation of the M/O flags, I believe the right > > solution is the following: > > I think we should be careful NOT to get hung up on what the original > intent of the M/O bits were, but focus on what the right behavior > should be, given what we know now/today, and given the DHC protocols > we actually have. > > The M/O bits were defined before we had DHCPv6 specified. I'd argue > that the M/O bits are a classic example of defining protocol/bits > before we really had a clear understanding of how they would be used, > what the semantics should be or what the actual protocols would be > that get invoked as a result of those bits. > > Surprise, surprise, when one invents protocols/mechanisms in such > cases, we often get the details wrong. > > Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 24 11:13:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab5i-0007Pj-Ps; Tue, 24 May 2005 11:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab5d-0007PB-T6 for ipv6@megatron.ietf.org; Tue, 24 May 2005 11:13:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09070 for ; Tue, 24 May 2005 11:13:03 -0400 (EDT) Received: from ccerelbas01.cce.hp.com ([161.114.21.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DabNp-00074v-Eb for ipv6@ietf.org; Tue, 24 May 2005 11:31:55 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.58]) by ccerelbas01.cce.hp.com (Postfix) with ESMTP id 8BFB7200021D; Tue, 24 May 2005 10:12:51 -0500 (CDT) Received: from cceexb11.americas.cpqcorp.net ([16.81.1.6]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:12:47 -0500 Received: from tayexb12.americas.cpqcorp.net ([16.103.130.102]) by cceexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 10:12:47 -0500 Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexb12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 11:12:46 -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, 24 May 2005 11:12:44 -0400 Message-ID: <936A4045C332714F975800409DE092404A0B92@tayexc14.americas.cpqcorp.net> Thread-Topic: purpose of m/o bit Thread-Index: AcVgb25TwdwI/HyIQyGACsRQNut72QAAzvNQ From: "Bound, Jim" To: "Thomas Narten" , X-OriginalArrivalTime: 24 May 2005 15:12:46.0057 (UTC) FILETIME=[0A51DD90:01C56073] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: purpose of m/o bit 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 > Does the community feel that operators need RA bits that > control/indicate whether a client is to invoke DHC? That is, is there > a need for the sys admin to signal to client whether DHC is to be > invoked? yes. >=20 > Second, is it important that such a signal be honored by clients? > (That is, if clients end up mostly ignoring the flags, does their > presence become useless?) That is not our business but yes I believe the market and clients will honor them as requirement from the organizations policy using stateful or other config info. >=20 > For example, should the sys admin be able to say "do not run DHC, > doing so wastes local resources and won't get you any config info"? > (And should that be honored by clients?) Sure just don't set the current bits in RAs. >=20 > Fundamentally, it is only the access network that has knowledge of > whether running DHC is useful. Thus, by default, clients (arguably) > can't know whether running DHC is useful, so by default they shold > invoke DHC (unless the sys admin signals "don't invoke DHC"). I think the m or o bit will be the decision policy point.=20 >=20 > Or (switching the argument), by default, client should not invoke DHC, > unless the local sys admin indicates doing so is appropriate. Corrrect same as question above. >=20 > If we can't agree that the above is necessary (i.e., is a "problem > statement" of sorts), I really have to wonder what purpose the R/A > bits can serve or whether we will ever have a shared understanding of > what they are supposed to do. Having them be a hint (that clients in > practice ignore half the time) would seem to solve no useful purpose > (IMO) and would provide the sys admin with useless tools (since > clients wouldn't respond to the usage of the tool in predicatable > ways). The result would simply be more confusion. (Oh, that is already > the state we are in!!! :-)) We agreed on this years ago. /jim >=20 > So, what is it?=20 >=20 > Thomas >=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 Tue May 24 11:35:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabRn-000497-JY; Tue, 24 May 2005 11:35:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabRk-00048a-Fh; Tue, 24 May 2005 11:35:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11488; Tue, 24 May 2005 11:35:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dabjx-00082I-Cl; Tue, 24 May 2005 11:54:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 May 2005 11:35:47 -0400 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 j4OFZS5C021409; Tue, 24 May 2005 11:35:44 -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, 24 May 2005 11:35:42 -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, 24 May 2005 11:35:41 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.com> Thread-Topic: purpose of m/o bit Thread-Index: AcVgb25TwdwI/HyIQyGACsRQNut72QAAzvNQAABTVGA= From: "Bernie Volz \(volz\)" To: "Bound, Jim" , "Thomas Narten" , , X-OriginalArrivalTime: 24 May 2005 15:35:42.0754 (UTC) FILETIME=[3EE52820:01C56076] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: purpose of m/o bit 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 Thomas/Jim: I believe that most of us are in agreement on the main points -- the bit(s) are useful and SHOULD be acted on by clients accordingly. I believe were there are issues are in the details about what each bit means and how they interact and what happens if they're not set correctly. Personally I think the last issue should be a non-issue since there are plenty of other parameters that need to be set correctly for networks to run. At worst, this causes clients not to get addresses (which will likely generate complaints to the network administrators fairly quickly) or wastes bandwidth. If we assume that current bits are retained, there is a problem if both the M and O bits are set with what a client should do if it supports both stateful and stateless DHCPv6 but fails to receive responses to Solicit requests. If the client only supports stateless DHCPv6, there is no issue since it just sends Information-Request messages. But if the client supports both (really this means it is a "full" 3315 client), does it do both in parallel, initiate stateful (Solicits) and failover to stateless at some point (and does it continue to do stateful in the background), or? These areas that are not well documented in the DHCPv6 specifications (3315 + 3736) and we need to clarify. We've discussed several proposals but I don't think we've closed that discussion. Having one bit instead of two doesn't really solve this problem since there is still the question of what a "full" 3315 client does when it fails to receive a response to Solicits or receives advertises that no addresses are available.=20 Though having one bit (saying run DHCPv6) does help as it simplifies the problem about what M=3D1 and O=3D0 means. Thus, I would suggest we: - Have one bit that says "run DHCPv6". If the client is stateful, it does "full" 3315". If the client is stateless (3736), it does stateless only. - Have the DHC WG publish a draft to properly define the behavior of clients (and servers) when stateful service is not available and only stateless is available. IE, when should a client switch to using Information-Request or should all servers support Solicit and should an Advertise be able to carry "other configuration" options when addresses are not available. (Or perhaps there are other options to be considered.) - Bernie > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bound, Jim > Sent: Tuesday, May 24, 2005 11:13 AM > To: Thomas Narten; ipv6@ietf.org > Subject: RE: purpose of m/o bit >=20 > =20 > > Does the community feel that operators need RA bits that > > control/indicate whether a client is to invoke DHC? That=20 > is, is there > > a need for the sys admin to signal to client whether DHC is to be > > invoked? >=20 > yes. >=20 > >=20 > > Second, is it important that such a signal be honored by clients? > > (That is, if clients end up mostly ignoring the flags, does their > > presence become useless?) >=20 > That is not our business but yes I believe the market and clients will > honor them as requirement from the organizations policy using stateful > or other config info. >=20 > >=20 > > For example, should the sys admin be able to say "do not run DHC, > > doing so wastes local resources and won't get you any config info"? > > (And should that be honored by clients?) >=20 > Sure just don't set the current bits in RAs. >=20 > >=20 > > Fundamentally, it is only the access network that has knowledge of > > whether running DHC is useful. Thus, by default, clients (arguably) > > can't know whether running DHC is useful, so by default they shold > > invoke DHC (unless the sys admin signals "don't invoke DHC"). >=20 > I think the m or o bit will be the decision policy point.=20 >=20 > >=20 > > Or (switching the argument), by default, client should not=20 > invoke DHC, > > unless the local sys admin indicates doing so is appropriate. >=20 > Corrrect same as question above. >=20 > >=20 > > If we can't agree that the above is necessary (i.e., is a "problem > > statement" of sorts), I really have to wonder what purpose the R/A > > bits can serve or whether we will ever have a shared=20 > understanding of > > what they are supposed to do. Having them be a hint (that clients in > > practice ignore half the time) would seem to solve no useful purpose > > (IMO) and would provide the sys admin with useless tools (since > > clients wouldn't respond to the usage of the tool in predicatable > > ways). The result would simply be more confusion. (Oh, that=20 > is already > > the state we are in!!! :-)) >=20 > We agreed on this years ago. >=20 > /jim > >=20 > > So, what is it?=20 > >=20 > > Thomas > >=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 > -------------------------------------------------------------------- >=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 May 24 12:18:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dac7H-0005Lx-4S; Tue, 24 May 2005 12:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dac7C-0005LQ-Uz; Tue, 24 May 2005 12:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15447; Tue, 24 May 2005 12:18:44 -0400 (EDT) Received: from tayrelbas02.tay.hp.com ([161.114.80.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DacPP-0001eF-SV; Tue, 24 May 2005 12:37:36 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas02.tay.hp.com (Postfix) with ESMTP id 8DDC515D; Tue, 24 May 2005 12:11:52 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 12:10:59 -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, 24 May 2005 12:10:56 -0400 Message-ID: <936A4045C332714F975800409DE092404A0BF8@tayexc14.americas.cpqcorp.net> Thread-Topic: purpose of m/o bit Thread-Index: AcVgb25TwdwI/HyIQyGACsRQNut72QAAzvNQAABTVGAAAcXpAA== From: "Bound, Jim" To: "Bernie Volz (volz)" , "Thomas Narten" , , X-OriginalArrivalTime: 24 May 2005 16:10:59.0114 (UTC) FILETIME=[2C5810A0:01C5607B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: purpose of m/o bit 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 Bernie, I think your honing down to valid points. I view m bit set implying o bit use too. but that is not stated. =20 /jim=20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 > Sent: Tuesday, May 24, 2005 11:36 AM > To: Bound, Jim; Thomas Narten; ipv6@ietf.org; dhcwg@ietf.org > Subject: RE: purpose of m/o bit >=20 > Thomas/Jim: >=20 > I believe that most of us are in agreement on the main points -- the > bit(s) are useful and SHOULD be acted on by clients accordingly. >=20 > I believe were there are issues are in the details about what each bit > means and how they interact and what happens if they're not set > correctly. >=20 > Personally I think the last issue should be a non-issue since=20 > there are > plenty of other parameters that need to be set correctly for=20 > networks to > run. At worst, this causes clients not to get addresses (which will > likely generate complaints to the network administrators=20 > fairly quickly) > or wastes bandwidth. >=20 > If we assume that current bits are retained, there is a=20 > problem if both > the M and O bits are set with what a client should do if it supports > both stateful and stateless DHCPv6 but fails to receive responses to > Solicit requests. >=20 > If the client only supports stateless DHCPv6, there is no=20 > issue since it > just sends Information-Request messages. >=20 > But if the client supports both (really this means it is a "full" 3315 > client), does it do both in parallel, initiate stateful (Solicits) and > failover to stateless at some point (and does it continue to=20 > do stateful > in the background), or? These areas that are not well=20 > documented in the > DHCPv6 specifications (3315 + 3736) and we need to clarify. We've > discussed several proposals but I don't think we've closed that > discussion. >=20 > Having one bit instead of two doesn't really solve this problem since > there is still the question of what a "full" 3315 client does when it > fails to receive a response to Solicits or receives advertises that no > addresses are available.=20 >=20 > Though having one bit (saying run DHCPv6) does help as it=20 > simplifies the > problem about what M=3D1 and O=3D0 means. >=20 > Thus, I would suggest we: > - Have one bit that says "run DHCPv6". If the client is stateful, it > does "full" 3315". If the client is stateless (3736), it does=20 > stateless > only. > - Have the DHC WG publish a draft to properly define the behavior of > clients (and servers) when stateful service is not available and only > stateless is available. IE, when should a client switch to using > Information-Request or should all servers support Solicit and=20 > should an > Advertise be able to carry "other configuration" options when=20 > addresses > are not available. (Or perhaps there are other options to be > considered.) >=20 > - Bernie >=20 >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > > Behalf Of Bound, Jim > > Sent: Tuesday, May 24, 2005 11:13 AM > > To: Thomas Narten; ipv6@ietf.org > > Subject: RE: purpose of m/o bit > >=20 > > =20 > > > Does the community feel that operators need RA bits that > > > control/indicate whether a client is to invoke DHC? That=20 > > is, is there > > > a need for the sys admin to signal to client whether DHC is to be > > > invoked? > >=20 > > yes. > >=20 > > >=20 > > > Second, is it important that such a signal be honored by clients? > > > (That is, if clients end up mostly ignoring the flags, does their > > > presence become useless?) > >=20 > > That is not our business but yes I believe the market and=20 > clients will > > honor them as requirement from the organizations policy=20 > using stateful > > or other config info. > >=20 > > >=20 > > > For example, should the sys admin be able to say "do not run DHC, > > > doing so wastes local resources and won't get you any=20 > config info"? > > > (And should that be honored by clients?) > >=20 > > Sure just don't set the current bits in RAs. > >=20 > > >=20 > > > Fundamentally, it is only the access network that has knowledge of > > > whether running DHC is useful. Thus, by default, clients=20 > (arguably) > > > can't know whether running DHC is useful, so by default they shold > > > invoke DHC (unless the sys admin signals "don't invoke DHC"). > >=20 > > I think the m or o bit will be the decision policy point.=20 > >=20 > > >=20 > > > Or (switching the argument), by default, client should not=20 > > invoke DHC, > > > unless the local sys admin indicates doing so is appropriate. > >=20 > > Corrrect same as question above. > >=20 > > >=20 > > > If we can't agree that the above is necessary (i.e., is a "problem > > > statement" of sorts), I really have to wonder what purpose the R/A > > > bits can serve or whether we will ever have a shared=20 > > understanding of > > > what they are supposed to do. Having them be a hint (that=20 > clients in > > > practice ignore half the time) would seem to solve no=20 > useful purpose > > > (IMO) and would provide the sys admin with useless tools (since > > > clients wouldn't respond to the usage of the tool in predicatable > > > ways). The result would simply be more confusion. (Oh, that=20 > > is already > > > the state we are in!!! :-)) > >=20 > > We agreed on this years ago. > >=20 > > /jim > > >=20 > > > So, what is it?=20 > > >=20 > > > Thomas > > >=20 > > >=20 > > >=20 > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests:=20 > https://www1.ietf.org/mailman/listinfo/ipv6 > > >=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 May 24 12:40:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacS3-0000SF-QN; Tue, 24 May 2005 12:40:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DacS2-0000SA-S7 for ipv6@megatron.ietf.org; Tue, 24 May 2005 12:40:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17500 for ; Tue, 24 May 2005 12:40:15 -0400 (EDT) Received: from tayrelbas02.tay.hp.com ([161.114.80.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DackG-0002gZ-0f for ipv6@ietf.org; Tue, 24 May 2005 12:59:08 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas02.tay.hp.com (Postfix) with ESMTP id 7863915E for ; Tue, 24 May 2005 12:40:05 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 12:38:02 -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, 24 May 2005 12:38:01 -0400 Message-ID: <936A4045C332714F975800409DE092404A0C23@tayexc14.americas.cpqcorp.net> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt Thread-Index: AcVgVlzLHwiRqNtwSLKAwi4zeSv/pAAFK2hwAATz++A= From: "Bound, Jim" To: X-OriginalArrivalTime: 24 May 2005 16:38:02.0489 (UTC) FILETIME=[F3F36E90:01C5607E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Subject: FW: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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 Resending. I did not see it come back to me. Sorry for duplicates if that is the case. /jim -----Original Message----- From: Bound, Jim=20 Sent: Tuesday, May 24, 2005 10:45 AM To: 'Brian Haberman'; IPv6 WG Cc: Bob Hinden Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt Brian and authors, My response below. Thus I cannot support this going to the IESG without further discussion as my input. I also support Margaret's request for this to be checked by RTSP persons, and I realize Dave T. clearly has this expertise but it is a good logic check. Unless we want to remove RSTP. I think we should include RSTP but it needs more review. General Comments: I also would like to see this work not focus at all on IPv4 and only address IPv6. The IPv4 work should be a separate document completely. To permit this behavior for prefixes to span links in IPv6 is a significant change to one of our architectural precepts for IPv6 and cannot be considered lightly, regarding link behavior.=20 Because it is an informational document I do not ask for implementation but it would be good to suggest this somewhere in the spec. If it were going to PS then implementation in this case is example where I think the IETF has to ask for that as it could negatively impact current and future deployment of IPv6. I would like to see a third scenario that aligns better with section 4. The two presented are ok but depicting two links with proxy between as in section 4 would be good scenario to add. I think DHCPv6 needs to be addressed when in use by the client and is missing in the discussion. Specific comments below: From=20 >3.1. Non-requirements >The following items are not considered requirements, as they are >not met by classic bridges: > The following additional items are not considered requirements for > this document: >o Support Neighbor Discovery, Router Discovery, or DHCPv4 > packets using IPsec. We also note that the current methods > for securing these protocols do not use IPsec so this is > considered acceptable. That IPsec will not be used or is not being used for ND is simply not valid or true. This may be an opinion or state for deployment by the authors but it is certainly not the view of all regarding deployment. Thus IPsec must be addressed if it is used and a statement what this means to the ndproxy proposal. I feel this is a hard requirement. This shows up again below as issue for me indirectly. From >4. Bridge-Like Proxy Behavior >As with all other interfaces, IPv4 and IPv6 maintain a neighbor >cache (aka "ARP cache") for each proxy interface, which will be >used as described below. For readability, we will describe the >neighbor cache as if both IPv4 and IPv6 neighbors use the same >state machine described in [ND]. That is not good to state IPv4 can use same abstraction as ND and gives the wrong impression to a reader. It simply is not true for most implementations. But, I would like IPv4 removed from this spec. The ND spec clearly documents the diffs and they are great enough to even compare or identify in this manner is not prudent in a specification. >4.1.3.3. DHCPv4 Packets Need section on DHCPv6. >4.1.4.3. ICMPv6 Router Advertisements >If an RA with the P bit set has arrived on a given interface >(including the upstream interface) within the last 60 minutes, >that interface MUST NOT be used as a proxy interface; i.e., proxy >functionality is disabled on that interface. The Proxy is acting as a router and this requirement for a P bit does affect router implementations and that was a non goal. This is a discrepancy and if the Proxy is a router it needs to adhere to that which a router must do and that needs to be added to the spec somewhere. >4.2. Originating Packets >P receives the solicitation (since it is receiving all link-layer >multicast packets) and processes it as it would any multicast >packet by forwarding it out to other segments on the link. >However, before actually sending the packet, it determines if the >packet being sent is one which requires proxying. Since it is an >NS, it creates a neighbor entry for A on interface 1 and records >its link-layer address. It also creates a neighbor entry for B >(on an arbitrary proxy interface) in the INCOMPLETE state. Since >the packet is multicast, P then needs to proxy the NS out all >other proxy interfaces on the subnet. Before sending the packet >out interface 2, it replaces the link-layer address in the SLLA >option with its own link-layer address, p2. This a routing function though a proxy and do we want to add this function to router requirements. This also has security issues that could cause DOS and affect data integrity of the network configuration parameters. =20 >6. Loop Prevention >Loop prevention using RSTP would typically be done by devices that >already implement this protocol as a result of supporting normal >briding functionality, and is done here as follows. IEEE 802 >interfaces use the protocol exactly as specified in [BRIDGE]. >Operation of RSTP over other types of link layers is done by >encapsulating the RSTP frame in an IPv6 header. The Next Header >field is set to [TBA by IANA], indicating that an RSTP header >follows. The Destination Address field is set to the Link-scoped >RSTP Multicast Group [TBA by IANA]. All proxies operating on non- >IEEE 802 media join this group so they will receive RSTP packets. >RSTP packets are never forwarded or proxied. Now packets are being added for NH and DST options and that needs to be checked if it is the best method to perform this function. It might be better as hop-by-hop option rather than DST option as thought. This should all be checked with RTSP WG in IETF. >Loop avoidance using the P bit in RAs is done as follows. The >proxy determines an "upstream" proxy interface, typically through >a physical choice dictated by the scenario (see Scenarios 1 and 2 >above), or through manual configuration. As described in Section >4.1.3.3, only the upstream interface is allowed to receive RAs, >and never from other proxies. Proxy functionality is disabled on >an interface otherwise. Finally, a proxy MUST wait until it has >sent two P bit RAs on a given "downstream" interface before it >enables forwarding on that interface. We have now used up precious bit space in ND and I do not see the justification unless we open this concept to working with general router implementations and that is what the proxy is in my view. >7. Guidelines to proxy developers This should be appendix not part of the specification. It is conjecture and suggestion that is all. >9. Security Considerations The security section is fair assessment but assuming SEND is not valid and many of us have many issues with SEND including but not limited to IPR, interface with PKIs, and that it does not assist with identification of the node on a wireless network. NDproxy now permits a rogue node to not only attack one link but now multiple links via the Proxy and thus exacerbates the entire problem we have with stateless wireless nodes in general. This needs to be added to the current list of security section. In addition I would like to see a softer support that SEND solves anything and a TBD. thanks /jim > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Brian Haberman > Sent: Tuesday, May 24, 2005 7:40 AM > To: IPv6 WG > Cc: Bob Hinden > Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt >=20 > IPv6 WG, > This begins a 1-week Working Group Last Call on advancing: >=20 > Title : Bridge-like Neighbor Discovery=20 > Proxies (ND Proxy) > Author(s) : D. Thaler, et al. > Filename : draft-ietf-ipv6-ndproxy-02.txt > Pages : 20 > Date : 2005-5-23 >=20 > as an Informational document. Substantive comments should be > directed to the mailing list. Minor comments and editorial issues can > be sent to the editor. This last call will end on June 3, 2005. >=20 > We also request that people comment on their support or opposition > to advancing this document. There has been mixed public support for > this work and it cannot advance without consensus from the working > group. >=20 > Regards, > Brian & Bob > IPv6 WG co-chairs >=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 May 24 15:45:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafKr-0006ri-3p; Tue, 24 May 2005 15:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DafKm-0006po-L8; Tue, 24 May 2005 15:45:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06749; Tue, 24 May 2005 15:44:58 -0400 (EDT) Message-Id: <200505241944.PAA06749@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 24 May 2005 15:44:58 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-2461bis-03.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Neighbor Discovery for IP version 6 (IPv6) Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-2461bis-03.txt Pages : 87 Date : 2005-5-24 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-2461bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-2461bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-24155023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-2461bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-2461bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-24155023.I-D@ietf.org> --OtherAccess-- --NextPart 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 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Tue May 24 19:32:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaitG-0008Jo-GM; Tue, 24 May 2005 19:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaitF-0008JZ-1Q for ipv6@megatron.ietf.org; Tue, 24 May 2005 19:32:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05709 for ; Tue, 24 May 2005 19:32:45 -0400 (EDT) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DajBW-0006TT-0a for ipv6@ietf.org; Tue, 24 May 2005 19:51:42 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id j4ONX7u3030068; Tue, 24 May 2005 18:33:07 -0500 Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L3YRCWPD; Tue, 24 May 2005 18:32:38 -0500 Received: from [142.133.72.115] ([142.133.72.115]) by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id j4ONWcXq004427; Tue, 24 May 2005 19:32:38 -0400 (EDT) Date: Tue, 24 May 2005 19:30:44 -0400 (EDT) X-Sybari-Trust: 54776e7d 94a8ae45 f576e2a9 00000139 From: Suresh Krishnan X-X-Sender: suresh@localhost.localdomain To: Margaret Wasserman In-Reply-To: Message-ID: References: <8DA338857B4F404282EE2088005079EA02B1C05E@eammlex037-nb.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ipv6@ietf.org, Suresh Krishnan Subject: Re: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 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 Margaret, Thanks for the comments and the text. I have submitted version -04 of the draft with the suggested changes. Let me know if you have any more issues you would like me to address. Cheers Suresh On Fri, 13 May 2005, Margaret Wasserman wrote: > At 10:15 AM -0400 5/11/05, Suresh Krishnan wrote: >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 >>> 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 >>> 1.2 Conventions used in this document . . . . . . . . . . . . 5 >>> >>>>> Why is the RFC 2119 section inside the problem statement? >> >> It is just another sub section under introduction to the document and is not >> under the problem statement. I can move this to a separate section if you >> feel strongly about this. > > Oh, okay... I viewed the Problem Statement and the Background both as parts > of the problem statement. Maybe if you just switched the order of 1.1 and 1.2 > (so the RFC 2119 language comes first), that would be better. Or, just ignore > this issue, as it is purely editorial. > >>> 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 >>> 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6 >>> 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7 >>> 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8 >>> 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9 >>> >>>>> Is section 2 supposed to be part of the problem statement? >> >> The problem statement is a concise description of the threat model we are >> defending against. Section 2 is a much more detailed study of the problems >> involved. The problem statement was created to provide the reader with some >> context as to why the document is needed. So the problem statement is a >> summary of sorts of section 2. > > Okay. > >>> 3. Protocol Description >>> >>> The goal of this section is to define procedures that: >>> >>> 1. Do not result in any changes to the basic behavior of addresses >>> generated via stateless address autoconfiguration [ADDRCONF]. >>> 2. Create additional global scope addresses based on a random >>> interface identifier for use with global scope addresses. >>> >>>>> What is meant by "for use with global addresses"? is this intended >>> to be a restriction on how/when privacy addresses can be used? >> >> This is not an intended restriction. I can reword it to read >> >> "2. Create additional addresses based on a random interface identifier for >> the purpose of initiating outgoing sessions" >> >> instead of >> >> "2. Create additional global scope addresses based on a random >> interface identifier for use with global scope addresses.Such >> addresses would be used to initiate outgoing sessions." >> >> Does that sound OK? > > Yes, that is better. > >>> 3.1 Assumptions >>> >>> The following algorithm assumes that each interface maintains an >>> associated randomized interface identifier. When temporary addresses >>> are generated, the current value of the associated randomized >>> interface identifier is used. The actual value of the identifier >>> changes over time as described below, but the same identifier can be >>> used to generate more than one temporary address. >>> >>> The algorithm also assumes that for a given temporary address, an >>> implementation can determine the prefix from which it was generated. >>> When a temporary address is deprecated, a new temporary address is >>> generated. The specific valid and preferred lifetimes for the new >>> address are dependent on the corresponding lifetime values set for >>> the prefix from which it was generated. >>> >>>>> These two paragraphs are confusing to me. The node maintains a >>> random IID from which multiple addresses can be generated of the >>> form , right? These addresses will become deprecated >>> when their lifetime expires, and new addresses will be generated. >>> The implementation keeps track of what prefix was used to generate >>> the addres and generates a new address for that prefix, right? >>> Does it also need to generate a new random IID when this happens? >>> In other words, is there anything in this mechanism that prevents >>> generating the same privacy address again on the same interface >>> using the same prefix and the same random IID (if it hasn't expired >>> yet)? >> >> The mechanism certainly allows this behavior but it kind of defeats the >> purpose(to not have a stable interface identifier). The requirement to >> change the random interface identifier is a SHOULD and is described in >> section 3.5 >> >> " Nodes following this specification SHOULD generate new temporary >> addresses on a periodic basis. This can be achieved automatically by >> generating a new randomized interface identifier at least once every >> (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units." >> >> If you think this is should be a stronger requirement I can change it to a >> MUST at the cost of breaking backward compatibility. Let me know what you >> prefer. > > The SHOULD is fine, but perhaps you could change the first paragraph of > section 3.1 to read: > > The following algorithm assumes that each interface maintains an > associated randomized interface identifier. When temporary addresses > are generated, the current value of the associated randomized > interface identifier is used. While the same identifier can be used to > create more than one temporary address, the value SHOULD change > over time as described in section 3.5. > > This would make it clearer that a person should look at section 3.5 to > understand how the identifier will change over time. > > Margaret > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 24 21:34:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaknB-0002cr-He; Tue, 24 May 2005 21:34:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dakn8-0002cc-FV for ipv6@megatron.ietf.org; Tue, 24 May 2005 21:34:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14578 for ; Tue, 24 May 2005 21:34:36 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dal5P-0001ux-LP for ipv6@ietf.org; Tue, 24 May 2005 21:53:33 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:74c5:e655:7a58:c31b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 07DBB15218; Wed, 25 May 2005 10:37:01 +0900 (JST) Date: Wed, 25 May 2005 10:35:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> References: <200505201724.j4KHOQ0j022198@rotala.raleigh.ibm.com> <200505241445.j4OEjJST025427@rotala.raleigh.ibm.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: 8abaac9e10c826e8252866cbe6766464 Cc: ipv6@ietf.org Subject: Re: purpose of m/o bit 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, 24 May 2005 10:45:19 -0400, >>>>> Thomas Narten said: > Does the community feel that operators need RA bits that > control/indicate whether a client is to invoke DHC? That is, is there > a need for the sys admin to signal to client whether DHC is to be > invoked? In my understanding of the past discussion (mainly for rfc2462bis), the "community" felt that operators need RA bits that control indicate whether a client "can" invoke DHC. The nuance might be slightly different from "is to" invoke DHC, but I think in general the answer was YES. And I don't think recent discussions change the base sense at that time. > Second, is it important that such a signal be honored by clients? > (That is, if clients end up mostly ignoring the flags, does their > presence become useless?) > For example, should the sys admin be able to say "do not run DHC, > doing so wastes local resources and won't get you any config info"? > (And should that be honored by clients?) Perhaps depending on the meaning of "honored", but it seems some people who have mobility background think YES, in that it is important to provide a way of signaling "do not run DHC" (when it's not available) for saving batteries (and perhaps network bandwidth). 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 May 24 21:46:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DakyM-0004dZ-Ms; Tue, 24 May 2005 21:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DakyI-0004bo-0n; Tue, 24 May 2005 21:46:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15336; Tue, 24 May 2005 21:46:08 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DalGa-0002Kw-An; Tue, 24 May 2005 22:05:04 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:74c5:e655:7a58:c31b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7544B15218; Wed, 25 May 2005 10:48:41 +0900 (JST) Date: Wed, 25 May 2005 10:47:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten In-Reply-To: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> References: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dhcwg@ietf.org, IPv6 WG Subject: Re: Original intent of M/O bits 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, 24 May 2005 10:46:06 -0400, >>>>> Thomas Narten said: >> If we respect both the original sense of RFC2462 and our consensus >> about the semantics separation of the M/O flags, I believe the right >> solution is the following: > I think we should be careful NOT to get hung up on what the original > intent of the M/O bits were, but focus on what the right behavior > should be, given what we know now/today, and given the DHC protocols > we actually have. In general, I agree (if I sound self-conflicting, note the "If" in the cited part above). In practice, however, it should also be noted that one major push back argument in the similar discussion for rfc2462bis a year ago was that we should not introduce incompatible changes to existing implementations that assume the "original intent". It seems to me that this is a typical case of tradeoff between "it's never too late to do the right thing" vs "don't break compatibility". In the previous discussion, the latter was preferred, and so we are here. If we can now prefer the former argument, I'm personally willing to take it. 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 May 24 22:08:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DalKA-0000Xs-P7; Tue, 24 May 2005 22:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DalK5-0000XK-Un; Tue, 24 May 2005 22:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16405; Tue, 24 May 2005 22:08:39 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DalcO-0002m7-6e; Tue, 24 May 2005 22:27:36 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:74c5:e655:7a58:c31b]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B348015218; Wed, 25 May 2005 11:11:12 +0900 (JST) Date: Wed, 25 May 2005 11:09:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.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: 52f7a77164458f8c7b36b66787c853da Cc: Thomas Narten , dhcwg@ietf.org, ipv6@ietf.org, "Bound, Jim" Subject: Re: purpose of m/o bit 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, 24 May 2005 11:35:41 -0400, >>>>> "Bernie Volz (volz)" said: > I believe were there are issues are in the details about what each bit > means and how they interact and what happens if they're not set > correctly. > Personally I think the last issue should be a non-issue since there are > plenty of other parameters that need to be set correctly for networks to > run. At worst, this causes clients not to get addresses (which will > likely generate complaints to the network administrators fairly quickly) > or wastes bandwidth. I agree. While I have repeatedly mentioned the latter case, I actually don't care about the case where a client cannot get addresses via DHCP due to incorrect M/O flags and/or misconfigured DHCPv6 servers. In this case, the user can do nothing but complain to the administrator. I'm more concerned about the case you mentioned in the succeeding lines (below), and it looks we are in some level of agreement. > If we assume that current bits are retained, there is a problem if both > the M and O bits are set with what a client should do if it supports > both stateful and stateless DHCPv6 but fails to receive responses to > Solicit requests. > If the client only supports stateless DHCPv6, there is no issue since it > just sends Information-Request messages. > But if the client supports both (really this means it is a "full" 3315 > client), does it do both in parallel, initiate stateful (Solicits) and > failover to stateless at some point (and does it continue to do stateful > in the background), or? These areas that are not well documented in the > DHCPv6 specifications (3315 + 3736) and we need to clarify. We've > discussed several proposals but I don't think we've closed that > discussion. Exactly. This is one of my major concerns, which I've been trying to address through the mo-flags draft with my co-authors (although we may not have been convincing enough in that work so far). > Thus, I would suggest we: > - Have one bit that says "run DHCPv6". If the client is stateful, it > does "full" 3315". If the client is stateless (3736), it does stateless > only. > - Have the DHC WG publish a draft to properly define the behavior of > clients (and servers) when stateful service is not available and only > stateless is available. IE, when should a client switch to using > Information-Request or should all servers support Solicit and should an > Advertise be able to carry "other configuration" options when addresses > are not available. (Or perhaps there are other options to be > considered.) If we can get the DHC draft soon (it's okay even if it's just an I-D), I think this is a reasonable approach. But since this (the first bullet more specifically) clearly results in a "backward-incompatible" change, we'll need a meta-level agreement for this approach. (In particular, we should consider how this affects the rfc2461bis work as an urgent issue) 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 May 24 23:15:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamMo-0002eZ-IP; Tue, 24 May 2005 23:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamMi-0002e2-LH; Tue, 24 May 2005 23:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19734; Tue, 24 May 2005 23:15:25 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Damez-0004UG-CS; Tue, 24 May 2005 23:34:23 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH000DHGZPEGS@mailout3.samsung.com>; Wed, 25 May 2005 12:15:14 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IH000I6TZPEPI@mmp2.samsung.com>; Wed, 25 May 2005 12:15:14 +0900 (KST) Date: Wed, 25 May 2005 12:15:10 +0900 From: "Soohong Daniel Park@samsung.com" In-reply-to: <8E296595B6471A4689555D5D725EBB212B40E1@xmb-rtp-20a.amer.cisco.com> To: "'Bernie Volz (volz)'" , "'Bound, Jim'" , "'Thomas Narten'" , ipv6@ietf.org, dhcwg@ietf.org Message-id: <010701c560d7$f5ad2f10$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Cc: Subject: RE: purpose of m/o bit 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 > But if the client supports both (really this means it is a "full" 3315 > client), does it do both in parallel, initiate stateful (Solicits) and > failover to stateless at some point (and does it continue to > do stateful in the background), or? These areas that are not well > documented in the DHCPv6 specifications (3315 + 3736) and we > need to clarify. We've discussed several proposals but I don't think > we've closed that discussion. Exactly, > Thus, I would suggest we: > - Have one bit that says "run DHCPv6". If the client is stateful, it > does "full" 3315". If the client is stateless (3736), it does stateless > only. > - Have the DHC WG publish a draft to properly define the behavior of > clients (and servers) when stateful service is not available and only > stateless is available. IE, when should a client switch to using > Information-Request or should all servers support Solicit and > should an Advertise be able to carry "other configuration" options > when addresses are not available. (Or perhaps there are other options > to be considered.) As Jinmei pointed out, we should consider *backward-incompatibility* proir to saying any alternatives. We should make sure that is not a trivial consideration. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, 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 May 24 23:23:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamUY-0003yk-Se; Tue, 24 May 2005 23:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DamUU-0003xa-5F; Tue, 24 May 2005 23:23:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20340; Tue, 24 May 2005 23:23:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Damml-0004oq-4G; Tue, 24 May 2005 23:42:25 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 May 2005 23:23:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4P3N05A004470; Tue, 24 May 2005 23:23:15 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 23:23:12 -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, 24 May 2005 23:23:09 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB213387C9@xmb-rtp-20a.amer.cisco.com> Thread-Topic: purpose of m/o bit Thread-Index: AcVg1/67duxFQIKcR3q8iX4krsvUxQAANLwQ From: "Bernie Volz \(volz\)" To: "Soohong Daniel Park@samsung.com" , "Bound, Jim" , "Thomas Narten" , , X-OriginalArrivalTime: 25 May 2005 03:23:12.0117 (UTC) FILETIME=[14AFEA50:01C560D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: purpose of m/o bit 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 have any issues if we wanted to keep 2 bits - just figured simpler is better. Note that if we drop one of those bits, we would not want to reuse if for another purpose for a long time -- that would allow backward compatibility for those environments that need it. But again, I really don't care if it is two bits. - Bernie=20 > -----Original Message----- > From: Soohong Daniel Park@samsung.com=20 > [mailto:soohong.park@samsung.com]=20 > Sent: Tuesday, May 24, 2005 11:15 PM > To: Bernie Volz (volz); 'Bound, Jim'; 'Thomas Narten';=20 > ipv6@ietf.org; dhcwg@ietf.org > Subject: RE: purpose of m/o bit >=20 > > But if the client supports both (really this means it is a=20 > "full" 3315 > > client), does it do both in parallel, initiate stateful=20 > (Solicits) and > > failover to stateless at some point (and does it continue to=20 > > do stateful in the background), or? These areas that are not well=20 > > documented in the DHCPv6 specifications (3315 + 3736) and we=20 > > need to clarify. We've discussed several proposals but I=20 > don't think=20 > > we've closed that discussion. >=20 > Exactly, >=20 > > Thus, I would suggest we: > > - Have one bit that says "run DHCPv6". If the client is stateful, it > > does "full" 3315". If the client is stateless (3736), it=20 > does stateless > > only. > > - Have the DHC WG publish a draft to properly define the behavior of > > clients (and servers) when stateful service is not=20 > available and only > > stateless is available. IE, when should a client switch to using > > Information-Request or should all servers support Solicit and=20 > > should an Advertise be able to carry "other configuration" options=20 > > when addresses are not available. (Or perhaps there are=20 > other options=20 > > to be considered.) >=20 > As Jinmei pointed out, we should consider *backward-incompatibility* > proir to saying any alternatives. We should make sure that is=20 > not a trivial=20 > consideration.=20 >=20 >=20 >=20 > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. >=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 May 25 00:09:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DanCe-0003nW-Ak; Wed, 25 May 2005 00:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DanCa-0003md-29; Wed, 25 May 2005 00:09:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26174; Wed, 25 May 2005 00:09:00 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DanUs-0006Ym-3Z; Wed, 25 May 2005 00:27:59 -0400 Received: from ep_mmp1 (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 <0IH1006RC26ATF@mailout1.samsung.com>; Wed, 25 May 2005 13:08:34 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH100IU126AXW@mmp1.samsung.com>; Wed, 25 May 2005 13:08:34 +0900 (KST) Date: Wed, 25 May 2005 13:08:29 +0900 From: "Soohong Daniel Park@samsung.com" In-reply-to: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> To: "'Thomas Narten'" , ipv6@ietf.org Message-id: <010801c560df$68a4c710$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7BIT Cc: dhcwg@ietf.org Subject: RE: purpose of m/o bit 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 > Does the community feel that operators need RA bits that > control/indicate whether a client is to invoke DHC? That is, is there > a need for the sys admin to signal to client whether DHC is to be > invoked? YES > Second, is it important that such a signal be honored by clients? > (That is, if clients end up mostly ignoring the flags, does their > presence become useless?) YES > If we can't agree that the above is necessary (i.e., is a "problem > statement" of sorts), I really have to wonder what purpose the R/A > bits can serve or whether we will ever have a shared understanding of > what they are supposed to do. Having them be a hint (that clients in > practice ignore half the time) would seem to solve no useful purpose > (IMO) and would provide the sys admin with useless tools (since > clients wouldn't respond to the usage of the tool in predicatable > ways). The result would simply be more confusion. (Oh, that is already > the state we are in!!! :-)) I don't think we (folks) do not agree on above necessary. We may need more simplified method to achieve above than now. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, 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 Wed May 25 00:37:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaneQ-0000RJ-UV; Wed, 25 May 2005 00:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaneM-0000R5-Ej; Wed, 25 May 2005 00:37:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28571; Wed, 25 May 2005 00:37:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Danwe-0007pL-QX; Wed, 25 May 2005 00:56:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 00:37:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4P4bUl6011351; Wed, 25 May 2005 00:37:32 -0400 (EDT) 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); Wed, 25 May 2005 00:37:29 -0400 Received: from 10.86.240.56 ([10.86.240.56]) 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 ; Wed, 25 May 2005 04:37:29 +0000 Received: from localhost.localdomain by email.cisco.com; 25 May 2005 00:37:39 -0400 From: Ralph Droms To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= In-Reply-To: References: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 22:39:41 -0400 Message-Id: <1116988781.5389.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 25 May 2005 04:37:29.0964 (UTC) FILETIME=[75C562C0:01C560E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , dhcwg@ietf.org, IPv6 WG Subject: Re: [dhcwg] Re: Original intent of M/O bits 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 Regarding breaking backward compatibility - this compatibility affects only clients, right? Can we answer the question: exactly how would existing clients (and I'll bet we can enumerate all the available clients) be affected by a change in definition? How would the observed behavior of the clients be out-of-spec relative to the new definition? I ask because I'd be willing to bet the observed behavior of existing clients will still be in compliance with the new definition: when the M bit is set, the client will attempt HCB and when the O bit is set the client will attempt ICB. When both are set, I'll bet the client tries HCB, which is still compliant with a new definition of M bit as a hint. - Ralph On Wed, 2005-05-25 at 10:47 +0900, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81= =94=E5=93=89 wrote: > >>>>> On Tue, 24 May 2005 10:46:06 -0400,=20 > >>>>> Thomas Narten said: >=20 > >> If we respect both the original sense of RFC2462 and our consensus > >> about the semantics separation of the M/O flags, I believe the right > >> solution is the following: >=20 > > I think we should be careful NOT to get hung up on what the original > > intent of the M/O bits were, but focus on what the right behavior > > should be, given what we know now/today, and given the DHC protocols > > we actually have. >=20 > In general, I agree (if I sound self-conflicting, note the "If" in the > cited part above). In practice, however, it should also be noted that > one major push back argument in the similar discussion for rfc2462bis > a year ago was that we should not introduce incompatible changes to > existing implementations that assume the "original intent". >=20 > It seems to me that this is a typical case of tradeoff between "it's > never too late to do the right thing" vs "don't break compatibility". > In the previous discussion, the latter was preferred, and so we are > here. If we can now prefer the former argument, I'm personally > willing to take it. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 01:50:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daomj-0005E6-MJ; Wed, 25 May 2005 01:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daome-0005CI-L2; Wed, 25 May 2005 01:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02665; Wed, 25 May 2005 01:50:23 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dap4x-0001hb-QB; Wed, 25 May 2005 02:09:21 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2456815218; Wed, 25 May 2005 14:52:50 +0900 (JST) Date: Wed, 25 May 2005 14:51:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms In-Reply-To: <1116988781.5389.5.camel@localhost.localdomain> References: <200505241446.j4OEk6WR025434@rotala.raleigh.ibm.com> <1116988781.5389.5.camel@localhost.localdomain> 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Thomas Narten , dhcwg@ietf.org, IPv6 WG Subject: Re: [dhcwg] Re: Original intent of M/O bits 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, 24 May 2005 22:39:41 -0400, >>>>> Ralph Droms said: > Regarding breaking backward compatibility - this compatibility affects > only clients, right? Can we answer the question: exactly how would > existing clients (and I'll bet we can enumerate all the available > clients) be affected by a change in definition? How would the observed > behavior of the clients be out-of-spec relative to the new definition? It depends on the details of the "new definition". For example, a "radical" change like removing the flags altogether would break the compatibility. I cannot be more specific at the moment, since the original message from Thomas did not show specific ideas... 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 Wed May 25 05:55:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DascD-0003zW-8m; Wed, 25 May 2005 05:55:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dasc9-0003zM-Nv; Wed, 25 May 2005 05:55:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23384; Wed, 25 May 2005 05:55:47 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DasuU-0008DR-4G; Wed, 25 May 2005 06:14:48 -0400 Received: from [194.229.202.133] ([194.229.202.133]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4P9tR2Z068998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 May 2005 11:55:46 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> References: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 25 May 2005 11:43:07 +0200 To: Thomas Narten X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: purpose of m/o bit 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 [Crossposted to dhcwg even though I'm not on that list, as people there may be able to add some useful insights.] On 24-mei-2005, at 16:45, Thomas Narten wrote: > I wonder if there is key question here that the community has simply > not agreed on (yet), and that that question is at the heart of all > this "confusion". > Does the community feel that operators need RA bits that > control/indicate whether a client is to invoke DHC? That is, is there > a need for the sys admin to signal to client whether DHC is to be > invoked? By a strange coincidence, I spent most of the day yesterday taking several DHCPv6 implementations for a test drive, for reasons unrelated to this discussion. These implementations are: KAME DHCP6, the unnamed Linux fork of the KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco IOS implemenation. Conclusion: the Cisco implementation is incomplete (no address assignment) and the other two are too immature to be of much use. I'm impressed with the prefix delegation functionality, but as before, the prospect of running such a complex protocol just to optain a domain search list and some DNS resolvers makes me very uncomfortable. All of this, coupled with the fact that, AFAIK, no OS implements DHCPv6, means that there is essentially zero experience with DHCPv6 in the operational community. This means that at this time, there is little point in asking the operational community what should happen with the M and O bits. In other words: this is not the time declare the bits useless and remove them. > Second, is it important that such a signal be honored by clients? > (That is, if clients end up mostly ignoring the flags, does their > presence become useless?) Depends. There are three possible ways this can play out: - the DNS resolver issue is solved in a way that doesn't requite DHCP, so most people don't don't run DHCPv6 at all, others run it all the time -> no bits necessary - the DNS resolver issue isn't solved in another way, so everyone runs some form of DHCPv6 all the time -> no bits necessary - DHCP provides benefits but some people are reluctant to use it -> helpful to know whether to bother running DHCPv6 > For example, should the sys admin be able to say "do not run DHC, > doing so wastes local resources and won't get you any config info"? > (And should that be honored by clients?) I think it's good to recognize that in the past, there have often been security issues with non-text based UDP protocols, so knowing there is no need to run DHCP and then not running it would be good security. > Fundamentally, it is only the access network that has knowledge of > whether running DHC is useful. Thus, by default, clients (arguably) > can't know whether running DHC is useful, so by default they shold > invoke DHC (unless the sys admin signals "don't invoke DHC"). > Or (switching the argument), by default, client should not invoke DHC, > unless the local sys admin indicates doing so is appropriate. There isn't really a difference here, except for what happens when there are no RAs. I would be interested in hearing viewpoints on the usefulness of running DHCPv6 even though the hints indicate that there is no need to. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 05:56:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DascR-00042T-KF; Wed, 25 May 2005 05:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DascP-00042L-T2; Wed, 25 May 2005 05:56:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23397; Wed, 25 May 2005 05:56:03 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dasum-0008Dy-Hv; Wed, 25 May 2005 06:15:04 -0400 Received: from [194.229.202.133] ([194.229.202.133]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4P9tR2a068998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 May 2005 11:55:55 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <936A4045C332714F975800409DE092404A0BF8@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092404A0BF8@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70760F06-F8FF-4694-94B8-7E2478FE36AB@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 25 May 2005 11:45:44 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: purpose of m/o bit 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 24-mei-2005, at 18:10, Bound, Jim wrote: > Bernie, I think your honing down to valid points. I view m bit set > implying o bit use too. but that is not stated. 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 08:05:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaudM-0008E4-UW; Wed, 25 May 2005 08:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaudL-0008Bl-7x for ipv6@megatron.ietf.org; Wed, 25 May 2005 08:05:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03723 for ; Wed, 25 May 2005 08:05:09 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dauvg-00044M-FC for ipv6@ietf.org; Wed, 25 May 2005 08:24:10 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 376187; Wed, 25 May 2005 08:00:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8DA338857B4F404282EE2088005079EA02B1C05E@eammlex037-nb.lmc.ericsson.se> Date: Wed, 25 May 2005 08:04:32 -0400 To: Suresh Krishnan From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org, Suresh Krishnan Subject: Re: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-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 Hi Suresh, Thanks for the quick turnaround! When the new draft comes out, I will send it to IETF LC. After we make it through IETF LC, the document will be reviewed by the full IESG. So, at this point, there are no further changes that need to be made, but you may need to make changes based on comments at either of those later review points. Thanks again for your quick response. Margaret At 7:30 PM -0400 5/24/05, Suresh Krishnan wrote: >Hi Margaret, > Thanks for the comments and the text. I have submitted version -04 >of the draft with the suggested changes. Let me know if you have any >more issues you would like me to address. > >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 May 25 08:28:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dauzl-0004yQ-C4; Wed, 25 May 2005 08:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dauzj-0004yF-43 for ipv6@megatron.ietf.org; Wed, 25 May 2005 08:28:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05969 for ; Wed, 25 May 2005 08:28:18 -0400 (EDT) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DavI5-0004cR-T7 for ipv6@ietf.org; Wed, 25 May 2005 08:47:19 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j4PCS8tV137428 for ; Wed, 25 May 2005 12:28:08 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4PCS70g251494 for ; Wed, 25 May 2005 13:28:07 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j4PCS7gx005949 for ; Wed, 25 May 2005 13:28:07 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j4PCS7Hg005940; Wed, 25 May 2005 13:28:07 +0100 Received: from zurich.ibm.com (sig-9-146-220-41.de.ibm.com [9.146.220.41]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA67102; Wed, 25 May 2005 14:28:06 +0200 Message-ID: <42946F53.4050101@zurich.ibm.com> Date: Wed, 25 May 2005 14:28:03 +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: "Bound, Jim" References: <936A4045C332714F975800409DE092403F05D4@tayexc14.americas.cpqcorp.net> In-Reply-To: <936A4045C332714F975800409DE092403F05D4@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: 6LSA Slides and QoS 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 Jim, you've stated that 6LSA respects the RFC 3697 requirement to deliver the original, unmodified flow label. draft-chakravorty-6lsa-01.txt makes that statement but does not define any mechanism to explain how it's done. As far as I can see, the ingress 6LSA router would have to signal downstream, and the egress 6LSA router would have to keep state. The mystery is solved in draft-chakravorty-bcc-fec-00.txt, where I find: > Because of the requirement to maintain the integrity of the Flow > Label field, the 6LSA switching technique can only be applied to > packets arriving at an edge port with their Flow Label field set to > zero. In future work on 6LSA, more generalized treatment of packets > that arrive with non-zero Flow Label will be presented. In other words, 6LSA as defined today is incapable of delivering the original flow label except for default traffic. That seems like a substantial limitation. Brian Bound, Jim wrote: > You can see good example of 6LSA in Charts at: > > http://www.nav6tf.org/documents/arin-nav6tf-apr05/5.QoS_and_IPv6_SC.pdf > > The rest of the slides for IPv6 may be interesting to some from this > joint ARIN+NAv6TF meeting too. > > http://www.nav6tf.org/html/nav6tf_events.html > > /jim > > -------------------------------------------------------------------- > 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 May 25 12:39:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayuV-0001yB-R8; Wed, 25 May 2005 12:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DayuU-0001y6-Fj for ipv6@megatron.ietf.org; Wed, 25 May 2005 12:39:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26186 for ; Wed, 25 May 2005 12:39:05 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DazCr-0002EL-FN for ipv6@ietf.org; Wed, 25 May 2005 12:58:11 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4PGcv0c675914 for ; Wed, 25 May 2005 12:38:57 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4PGcv3f133852 for ; Wed, 25 May 2005 10:38:57 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4PGcvFX010235 for ; Wed, 25 May 2005 10:38:57 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4PGcuUL009863 for ; Wed, 25 May 2005 10:38:56 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4PGce38002143 for ; Wed, 25 May 2005 12:38:50 -0400 Message-Id: <200505251638.j4PGce38002143@rotala.raleigh.ibm.com> To: ipv6@ietf.org In-Reply-To: Message from iesg-secretary@ietf.org of "Mon, 02 May 2005 14:16:25 EDT." Date: Wed, 25 May 2005 12:38:40 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' 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 I've reviewed this document and on the whole think it's fine for PS. But I do have one general concern. This document requires that an implementation do what in practice, I think might be "difficult" for some implementations. While that is OK at one level, I fear that some implementors will do most of this spec, but not all of it. I wonder if that would be a good outcome. For example: > * (modifies 7.2.2) When a node has a unicast packet to send from an > Optimistic Address to a neighbor, but does not know the > neighbor's link-layer address, it MUST NOT perform Address > Resolution. It SHOULD forward the packet to a default router on > the link in the hope that the packet will be redirected. > Otherwise it SHOULD buffer the packet until DAD is complete. will implementations really bother with this? Or will they be tempted to skip this because it is "too hard" for a particular implementation? > * Nodes implementing Optimistic DAD SHOULD additionally implement > Secure Neighbor Discovery [SEND]. This seems like gratuitous recommendation. This either requires justification, or removal. (I'd think the latter.) > Tentative Address - an address for which a node has not yet completed > DAD is regarded as Tentative: a single Neighbor Solicitation for > this address or a single Neighbor Advertisement defending this > address will cause the node to deconfigure the address and cease > using it. > > Deprecated Address - an address which should not be used if an > alternative is available. > Wouldn't it be better to just use the same definitions as appears in 2462? Editorial/minor: > Optimistic Address - an address which is available for use despite > DAD not being fully complete. This memo places restrictions on > the use of Optimistic Addresses. > s/which/that/ > Standard Node - A Standard Node is one which is compliant with RFCs > 2461 and 2462. > s/standard/conventional/? (nodes implementing this spec will be "standard" too) > * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation > for an Optimistic Address from the unspecified address. This NS > indicates that the address is a duplicate, and it MUST be > deconfigured as per the behaviour specified in RFC2462 for > Tentative addresses. Suggested reword of second sentence:: Receipt of such an NS indicates that the address is ... > The ON will immediately send out a Neighbor Solicitation to determine > if its new address is already in use. s/new/optimistic/ > router behaviour, eg: that the router includes SLLAOs in RAs, and s/eg:/e.g.,/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 13:14:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DazSi-0000k3-Pb; Wed, 25 May 2005 13:14:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DazSf-0000ic-GO for ipv6@megatron.ietf.org; Wed, 25 May 2005 13:14:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01338 for ; Wed, 25 May 2005 13:14:26 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dazl5-0003Lq-7O for ipv6@ietf.org; Wed, 25 May 2005 13:33:32 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 May 2005 13:14:18 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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, 25 May 2005 13:14:11 -0400 Message-ID: Thread-Topic: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed Standard Thread-Index: AcVhSP34WibJUXCYS2ax2RfAw5KDhwABAx0Q From: "Soliman, Hesham" To: "Thomas Narten" , X-OriginalArrivalTime: 25 May 2005 17:14:18.0802 (UTC) FILETIME=[2F8C3120:01C5614D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 > > * Nodes implementing Optimistic DAD SHOULD additionally=20 > implement > > Secure Neighbor Discovery [SEND]. >=20 > This seems like gratuitous recommendation. This either requires > justification, or removal. (I'd think the latter.) =3D> Agreed. I think it should be removed as it's more general than the optDAD case.=20 Hesham =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 Wed May 25 13:22:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daza1-00028V-Er; Wed, 25 May 2005 13:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DazZy-00027k-Jw; Wed, 25 May 2005 13:22:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02294; Wed, 25 May 2005 13:21:59 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DazsK-0003aQ-A2; Wed, 25 May 2005 13:41:05 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:1db7:2189:3231:e775]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3609415218; Thu, 26 May 2005 02:24:28 +0900 (JST) Date: Thu, 26 May 2005 02:22:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Iljitsch van Beijnum In-Reply-To: <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.com> References: <200505241445.j4OEjJST025427@rotala.raleigh.ibm.com> <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.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: Thomas Narten , dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: [dhcwg] Re: purpose of m/o bit 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, 25 May 2005 11:43:07 +0200, >>>>> Iljitsch van Beijnum said: > These implementations are: KAME DHCP6, the unnamed Linux fork of the > KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco > IOS implemenation. > Conclusion: the Cisco implementation is incomplete (no address > assignment) and the other two are too immature to be of much use. > I'm impressed with the prefix delegation functionality, but as > before, the prospect of running such a complex protocol just to > optain a domain search list and some DNS resolvers makes me very > uncomfortable. A quick check (which may not be relevant to this thread): what exactly do you mean by such a complex protocol? Whole RFC3315 (mainly for address allocation), the RFC3736 subset, or both? If your goal is to obtain a domain search list and recursive name (DNS) servers, you only need the RFC3736 subset, and at least I'd not use the strong phrase "such a complex protocol" for RFC3736. Implementation maturity is a separate issue. I admit KAME's DHCPv6 implementation is not so matured yet, particularly regarding its address allocation functionality. 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 Wed May 25 13:55:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db064-0008Au-8X; Wed, 25 May 2005 13:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db060-0008Aj-51; Wed, 25 May 2005 13:55:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04509; Wed, 25 May 2005 13:55:07 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db0OO-0004IH-W3; Wed, 25 May 2005 14:14:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 25 May 2005 13:54:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4PHsI5O024436; Wed, 25 May 2005 13:54:54 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 13:54:52 -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, 25 May 2005 13:54:51 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB213388DD@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVhHmGDmhPx71eeTiSg0e2QoYJwKAAMSD8AAADP6CA= From: "Bernie Volz \(volz\)" To: "Woundy, Richard" , "Iljitsch van Beijnum" , "Thomas Narten" X-OriginalArrivalTime: 25 May 2005 17:54:52.0679 (UTC) FILETIME=[DA405970:01C56152] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit 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 Rich, I'll ask. What would you like to see happen? - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Woundy, Richard > Sent: Wednesday, May 25, 2005 1:39 PM > To: Iljitsch van Beijnum; Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: RE: [dhcwg] Re: purpose of m/o bit >=20 > >All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 in > the operational community. This means that at this time,=20 > there is little > point in asking the operational community what should happen=20 > with the M > and O bits. >=20 > Or perhaps this could be the ideal time to ask the=20 > operational community > what should happen with the M and O bits -- before software developers > go too far down a particular direction without operator guidance? >=20 > Some of us operators do more than just configure and test vendor > products. >=20 > -- Rich >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Iljitsch van Beijnum > Sent: Wednesday, May 25, 2005 5:43 AM > To: Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit >=20 >=20 > [Crossposted to dhcwg even though I'm not on that list, as people =20 > there may be able to add some useful insights.] >=20 > On 24-mei-2005, at 16:45, Thomas Narten wrote: >=20 > > I wonder if there is key question here that the community=20 > has simply=20 > > not agreed on (yet), and that that question is at the heart of all=20 > > this "confusion". >=20 > > Does the community feel that operators need RA bits that=20 > > control/indicate whether a client is to invoke DHC? That=20 > is, is there=20 > > a need for the sys admin to signal to client whether DHC is to be=20 > > invoked? >=20 > By a strange coincidence, I spent most of the day yesterday taking =20 > several DHCPv6 implementations for a test drive, for reasons =20 > unrelated to this discussion. >=20 > These implementations are: KAME DHCP6, the unnamed Linux fork of the =20 > KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco =20 > IOS implemenation. >=20 > Conclusion: the Cisco implementation is incomplete (no address =20 > assignment) and the other two are too immature to be of much use. >=20 > I'm impressed with the prefix delegation functionality, but as =20 > before, the prospect of running such a complex protocol just to =20 > optain a domain search list and some DNS resolvers makes me very =20 > uncomfortable. >=20 > All of this, coupled with the fact that, AFAIK, no OS implements =20 > DHCPv6, means that there is essentially zero experience with DHCPv6 =20 > in the operational community. This means that at this time, there is =20 > little point in asking the operational community what should happen =20 > with the M and O bits. >=20 > In other words: this is not the time declare the bits useless and =20 > remove them. >=20 > > Second, is it important that such a signal be honored by clients?=20 > > (That is, if clients end up mostly ignoring the flags, does their=20 > > presence become useless?) >=20 > Depends. There are three possible ways this can play out: >=20 > - the DNS resolver issue is solved in a way that doesn't requite =20 > DHCP, so most people don't don't run DHCPv6 at all, others=20 > run it all =20 > the time -> no bits necessary > - the DNS resolver issue isn't solved in another way, so everyone =20 > runs some form of DHCPv6 all the time -> no bits necessary > - DHCP provides benefits but some people are reluctant to use it -> =20 > helpful to know whether to bother running DHCPv6 >=20 > > For example, should the sys admin be able to say "do not run DHC,=20 > > doing so wastes local resources and won't get you any config info"?=20 > > (And should that be honored by clients?) >=20 > I think it's good to recognize that in the past, there have often =20 > been security issues with non-text based UDP protocols, so knowing =20 > there is no need to run DHCP and then not running it would be good =20 > security. >=20 > > Fundamentally, it is only the access network that has knowledge of=20 > > whether running DHC is useful. Thus, by default, clients (arguably)=20 > > can't know whether running DHC is useful, so by default they shold=20 > > invoke DHC (unless the sys admin signals "don't invoke DHC"). >=20 > > Or (switching the argument), by default, client should not=20 > invoke DHC, >=20 > > unless the local sys admin indicates doing so is appropriate. >=20 > There isn't really a difference here, except for what happens when =20 > there are no RAs. >=20 > I would be interested in hearing viewpoints on the usefulness of =20 > running DHCPv6 even though the hints indicate that there is=20 > no need to. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=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 May 25 14:47:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db0ug-0007nK-On; Wed, 25 May 2005 14:47:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db0uc-0007mR-TU for ipv6@megatron.ietf.org; Wed, 25 May 2005 14:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07874 for ; Wed, 25 May 2005 14:47:25 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db1D3-0005LX-2R for ipv6@ietf.org; Wed, 25 May 2005 15:06:30 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E494089832; Wed, 25 May 2005 21:47:12 +0300 (EEST) Message-ID: <4294C840.5030007@kolumbus.fi> Date: Wed, 25 May 2005 21:47:28 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , ipv6@ietf.org Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 Soliman, Hesham wrote: > > > * Nodes implementing Optimistic DAD SHOULD additionally > > implement > > > Secure Neighbor Discovery [SEND]. > > > > This seems like gratuitous recommendation. This either requires > > justification, or removal. (I'd think the latter.) > >=> Agreed. I think it should be removed as it's more general than >the optDAD case. > > Yes. The right place for this statement is in the ND specifications, unless optimistic DAD would somehow have tougher security requirements (which I don't think is the case). --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 15:00:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db16z-0001bz-OM; Wed, 25 May 2005 15:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db16x-0001b0-L1 for ipv6@megatron.ietf.org; Wed, 25 May 2005 15:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09115 for ; Wed, 25 May 2005 15:00:10 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db1PL-0005j3-U5 for ipv6@ietf.org; Wed, 25 May 2005 15:19:15 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:1db7:2189:3231:e775]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5590C15218; Thu, 26 May 2005 04:02:42 +0900 (JST) Date: Thu, 26 May 2005 04:01:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 24 May 2005 10:04:25 -0400, >>>>> "Soliman, Hesham" said: > Hi all, > I submitted an updated revision of 2461bis which includes > the resolutions that were agreed on by the WG in the last meeting > (the SLLAO thread). It also includes fixes for the comments Tatuya > raised on the last version. > I think this draft is now ready for the IESG. I've not fully checked the entire new version, but from a quick glance the following comment of mine does not seem to be addressed: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04811.html http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html At the very least, the 4th paragraph of Section 7.2.5 needs an editorial fix for oddly short lines: If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happen: If the advertisement were solicited, the state is changed to REACHABLE. Otherwise, the state is set to STALE. Note that the Override flag is -> ignored if the entry is in the -> INCOMPLETE state. 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 Wed May 25 15:02:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db19A-0001zR-71; Wed, 25 May 2005 15:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db198-0001zM-1b for ipv6@megatron.ietf.org; Wed, 25 May 2005 15:02:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09318 for ; Wed, 25 May 2005 15:02:24 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db1RY-0005m4-8t for ipv6@ietf.org; Wed, 25 May 2005 15:21:29 -0400 Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4PJ2HGJ020884; Wed, 25 May 2005 12:02:17 -0700 (PDT) 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 j4PJ26oI332508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2005 12:02:07 -0700 (PDT) Message-ID: <4294CBCA.2090605@sun.com> Date: Wed, 25 May 2005 12:02:34 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: <8c036d2bf506cf369f56477701e54db8@innovationslab.net> 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Bob Hinden , Brian Haberman , IPv6 WG Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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 Margaret Wasserman wrote: > Could the current chairs perhaps comment on how they believe that the ND > Proxy document, as it currently exists, fits within the IPv6 WG > charter? Is there anyone else who has an opinion on this? > > This is not merely a legalistic concern. I am concerned that the people > who should be involved in the standardization an RSTP-based L3 bridging > technology may not be involved in the IPv6 WG. In fact, they may not > even be aware that this work is underway here. Therefore, this document > may not have been developed and reviewed by a group that has the balance > of experience needed to reach valid IETF consensus on this work. FWIW I'm also concerned that the RSTP part of the protocol might not be as well understood. I've discovered that at least STP makes assumptions about the failure of the underlying "transport", such as the failures being visible to the STP. This is satisfied when the "transport" is IEEE 802.3 etc, because the link layer provides some form of "link test", but wouldn't be satisfied when just encapsulating STP in IPv6. It *might be* that RSTP (IEEE 802.1D-2004 with its addenda and corrigenda, and not necessarily the stuff that vendors claim being RSTP), does not make that assumption, but before putting out a specification that carries IEEE 802.1D-2004 over IPv6, I think we should verify this with the experts in IEEE 802.1. Alternatively, we can go limit the draft to handling the simple cases (with the 'P' bit as a way to detect loops and shut them off). 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 May 25 15:54:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1xX-0003jD-P9; Wed, 25 May 2005 15:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1xU-0003iY-2D; Wed, 25 May 2005 15:54:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16297; Wed, 25 May 2005 15:54:26 -0400 (EDT) Message-Id: <200505251954.PAA16297@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 25 May 2005 15:54:26 -0400 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-privacy-addrs-v2-04.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, et al. Filename : draft-ietf-ipv6-privacy-addrs-v2-04.txt Pages : 32 Date : 2005-5-25 Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-privacy-addrs-v2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-25160155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-privacy-addrs-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-25160155.I-D@ietf.org> --OtherAccess-- --NextPart 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 -------------------------------------------------------------------- --NextPart-- From ipv6-bounces@ietf.org Wed May 25 20:12:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5z4-0002Yq-A2; Wed, 25 May 2005 20:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db5z0-0002Yl-So for ipv6@megatron.ietf.org; Wed, 25 May 2005 20:12:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10565 for ; Wed, 25 May 2005 20:12:17 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db6HT-0006yh-Na for ipv6@ietf.org; Wed, 25 May 2005 20:31:25 -0400 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPKY418H0975WZL@vaxc.its.monash.edu.au> for ipv6@ietf.org; Thu, 26 May 2005 10:12:10 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E8513AB544; Thu, 26 May 2005 10:12:09 +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 9B6554FB04; Thu, 26 May 2005 10:12:09 +1000 (EST) Date: Thu, 26 May 2005 10:12:03 +1000 From: Greg Daley In-reply-to: <200505251638.j4PGce38002143@rotala.raleigh.ibm.com> To: Thomas Narten Message-id: <42951453.8050504@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: <200505251638.j4PGce38002143@rotala.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' to Proposed Standard 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 Thomas. Thomas Narten wrote: > I've reviewed this document and on the whole think it's fine for PS. > > But I do have one general concern. This document requires that an > implementation do what in practice, I think might be "difficult" for > some implementations. While that is OK at one level, I fear that some > implementors will do most of this spec, but not all of it. I wonder if > that would be a good outcome. > > For example: > > >> * (modifies 7.2.2) When a node has a unicast packet to send from an >> Optimistic Address to a neighbor, but does not know the >> neighbor's link-layer address, it MUST NOT perform Address >> Resolution. It SHOULD forward the packet to a default router on >> the link in the hope that the packet will be redirected. >> Otherwise it SHOULD buffer the packet until DAD is complete. > > > will implementations really bother with this? Or will they be tempted > to skip this because it is "too hard" for a particular implementation? I guess that the forwarding to the router may be difficult as also may the buffering of the packets (which I guess actually may be part of the existing tentative address specification). Neither is actually as important as the first instruction (the MUST NOT). What's actually critical here is that NS's aren't sent to multicast addresses. They contain SLLAOs which will overwrite a peer's NCE destructively. So my question is: Is your problem mainly with the SHOULDs or the MUST NOT? 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 May 25 21:05:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6oN-0007XK-J3; Wed, 25 May 2005 21:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6oL-0007XE-T6 for ipv6@megatron.ietf.org; Wed, 25 May 2005 21:05:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18361 for ; Wed, 25 May 2005 21:05:18 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db76n-0000uo-I2 for ipv6@ietf.org; Wed, 25 May 2005 21:24:26 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q159oO016957 for ; Wed, 25 May 2005 21:05:09 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4Q1595Z156634 for ; Wed, 25 May 2005 21:05:09 -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 j4Q159B6011941 for ; Wed, 25 May 2005 21:05:09 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-209-95.mts.ibm.com [9.65.209.95]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q158Pb011914; Wed, 25 May 2005 21:05:09 -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 j4Q13kX6004739; Wed, 25 May 2005 21:03:47 -0400 Message-Id: <200505260103.j4Q13kX6004739@cichlid.raleigh.ibm.com> To: greg.daley@eng.monash.edu.au In-Reply-To: Message from Greg Daley of "Thu, 26 May 2005 10:12:03 +1000." <42951453.8050504@eng.monash.edu.au> Date: Wed, 25 May 2005 21:03:46 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipv6@ietf.org Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' 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 > > I've reviewed this document and on the whole think it's fine for PS. > > > > But I do have one general concern. This document requires that an > > implementation do what in practice, I think might be "difficult" for > > some implementations. While that is OK at one level, I fear that some > > implementors will do most of this spec, but not all of it. I wonder if > > that would be a good outcome. BTW, what I meant to say above was more like: This document requires that an implementation do things that may logically (if you follow the conceptual sending model) be hard to do, because the information needed to do something may not be available at that point in the algorithm (implementation). I.e., one ends up having to have access to the ND cache info while doing steps that (previously) were logically completely separate from the ND cache. I wonder if in practice, these might be "difficult" for some implementations. > > For example: > > > > > >> * (modifies 7.2.2) When a node has a unicast packet to send from an > >> Optimistic Address to a neighbor, but does not know the > >> neighbor's link-layer address, it MUST NOT perform Address > >> Resolution. It SHOULD forward the packet to a default router on > >> the link in the hope that the packet will be redirected. > >> Otherwise it SHOULD buffer the packet until DAD is complete. > > > > > > will implementations really bother with this? Or will they be tempted > > to skip this because it is "too hard" for a particular implementation? > I guess that the forwarding to the router may be difficult as also may > the buffering of the packets (which I guess actually may be part > of the existing tentative address specification). > Neither is actually as important as the first instruction > (the MUST NOT). If you only do the MUST NOT, but not the SHOULDs, what is the point of implementing the spec? You are allowing an upper layer to use a tentative address, yet packets from that address presumably won't be sent until (the normal) DAD has completed, in which case, you've paid the price of the normal DAD delay... Right? > What's actually critical here is that NS's aren't sent to multicast > addresses. They contain SLLAOs which will overwrite a peer's NCE > destructively. > So my question is: Is your problem mainly with the SHOULDs or the > MUST NOT? Am I understanding correctly that not implementing the SHOULD effectively negates the benefits of implementing the spec? Well, maybe it depends also on what one expects the first packets to be that a node sends. I.e., if they are for non-neighbors (i.e., off-link) and would go through the router, then that traffic would get sent immediately. But it appears that at least when sending to neighbors, not implementing the SHOULDs results in no reduction in delay. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 21:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6q4-0007jY-08; Wed, 25 May 2005 21:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6q2-0007jQ-EV for ipv6@megatron.ietf.org; Wed, 25 May 2005 21:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18479 for ; Wed, 25 May 2005 21:07:05 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db78W-0000wx-8F for ipv6@ietf.org; Wed, 25 May 2005 21:26:13 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 May 2005 21:06:55 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2005 21:06:53 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVhW/jzw4JBpf4gR+6GhlS6B8/OewAMwy8g From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 May 2005 01:06:55.0653 (UTC) FILETIME=[358C4550:01C5618F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis update 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,=20 This comment was concerned with removing=20 the "not" the preceded INCOMPLETE. Peter (who raised the comment) said he's happy with just the removal, which was a typo. So what else=20 needs to be done? Hesham > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp=20 > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Wednesday, May 25, 2005 3:01 PM > To: Soliman, Hesham > Cc: ipv6@ietf.org > Subject: Re: 2461bis update >=20 >=20 > >>>>> On Tue, 24 May 2005 10:04:25 -0400,=20 > >>>>> "Soliman, Hesham" said: >=20 > > Hi all, > > I submitted an updated revision of 2461bis which includes=20 > > the resolutions that were agreed on by the WG in the last meeting > > (the SLLAO thread). It also includes fixes for the comments Tatuya > > raised on the last version.=20 >=20 > > I think this draft is now ready for the IESG.=20 >=20 > I've not fully checked the entire new version, but from a=20 > quick glance > the following comment of mine does not seem to be addressed: >=20 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04811.html > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html >=20 > At the very least, the 4th paragraph of Section 7.2.5 needs an > editorial fix for oddly short lines: >=20 > If the target's Neighbor Cache entry is in the=20 > INCOMPLETE state when > the advertisement is received, one of two things happen: If the > advertisement were solicited, the state is changed to REACHABLE. > Otherwise, the state is set to STALE. Note that the=20 > Override flag is > -> ignored if the entry is in the > -> INCOMPLETE state. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Wed May 25 21:55:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7ap-0007tF-Ps; Wed, 25 May 2005 21:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7an-0007s6-UB for ipv6@megatron.ietf.org; Wed, 25 May 2005 21:55:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21645 for ; Wed, 25 May 2005 21:55:24 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db7tF-0001zM-Jr for ipv6@ietf.org; Wed, 25 May 2005 22:14:33 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:1db7:2189:3231:e775]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 53AA415218; Thu, 26 May 2005 10:57:35 +0900 (JST) Date: Thu, 26 May 2005 10:55:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 25 May 2005 21:06:53 -0400,=20 >>>>> "Soliman, Hesham" said: > This comment was concerned with removing=20 > the "not" the preceded INCOMPLETE. Peter (who raised the comment) > said he's happy with just the removal, which was a typo. So what else=20 > needs to be done? I thought I had explained that in the previous message: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04811.html and made it clear that this is a separate issue of the original one from Peter's: I don't know the background of this change, even if we removed the "not".= .. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^ But, in case I was not clear enough, the point is that the relevant change from RFC2461 to rfc2461bis makes the text rather unreadable. So, I'd first like to know the intent of the change. One specific point at the moment: Section 7.2.5 of draft-ietf-ipv6-2461bis-03.txt reads: If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happen: If the advertisement were solicited, the state is changed to REACHABLE. Otherwise, the state is set to STALE. Note that the Override flag is ignored if the entry is in the INCOMPLETE state. =46rom this paragraph, the "two things" would be: 1. If the advertisement were solicited, the state is changed to REACHABLE. 2. Otherwise, the state is set to STALE. On the other hand, the corresponding part of RFC2461 was: If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. Otherwise, the receiving node performs the following steps: (....) =46rom this paragraph, the "two things" would be: 1. If the link layer has addresses and no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. 2. Otherwise, the receiving node performs the following steps: (....) So, while the beginning part is exactly the same, the "two things" seem to refer to completely different things. The difference itself is not necessarily a problem. However, rfc2461bis-03 then repeats its "two things": - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. Now this make me really confused... Additionally, the relationship between the two parts beginning with "If the (target's) Neighbor Cache entry is in the INCOMPLETE state" is not very clear to me: If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happen: (...) If the Neighbor Cache entry is in INCOMPLETE state, the receiving node performs the following steps: (...) Note that the second part was one of the "two things" in original RFC2461. All of these things just confused me about what this part wanted to convey. So, again, I'd first like to know the intent of the change, and then I'm willing to suggest explicit text according to the intent. I hope this time I'm clear enough. Thanks, 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 Wed May 25 22:17:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7wD-0003bQ-4A; Wed, 25 May 2005 22:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db7wB-0003bG-B2 for ipv6@megatron.ietf.org; Wed, 25 May 2005 22:17:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23152 for ; Wed, 25 May 2005 22:17:29 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db8Eg-0002VU-Ba for ipv6@ietf.org; Wed, 25 May 2005 22:36:39 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 May 2005 22:17:20 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2005 22:17:19 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVhle1gcbPVHJwtTfa2WeNSSY+PeAAAb7aA From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 May 2005 02:17:20.0763 (UTC) FILETIME=[0BE8E4B0:01C56199] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis update 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 section was changed based on comments from Pekka and yourself. Note = that I'm referring to the section as a whole and not only the first = paragraph. I don't remember the intent of changing every line since I changed the whole section in = rev 2. But=20 the main reason for the change was clarifications and no substantial = change was made. The current text, I believe (please correct me if I'm wrong) conveyed = the same=20 message as the previous section in 2461. It seems that one of the = sources=20 of the confusion is that you're assuming the "two things" text must = refer to the same thing in 2461bis as it did in 2461. That's not the case of = course.=20 So to avoid meddling with text unnecessarily, I would ask you to tell me = if this section (in 2461bis) does anything differently to = implementations from=20 the same section in 2461. If that's the case, please let us know and = I'll fix it.=20 Or, if the text is not clear, I'm happy to fix it. But the only lack of = clarity you=20 point to below is a result of comparing ordering of text in the current = revision with the corresponding one in 2461. It doesn't need to be the same thing (as = you point out below) as long as=20 the result is the same for implementations.=20 In any case, if there is anything to be done, I think we should add that = to the IESG comments. I'm sure they'll require changes to text.=20 Hesham > But, in case I was not clear enough, the point is that the relevant > change from RFC2461 to rfc2461bis makes the text rather unreadable. > So, I'd first like to know the intent of the change. >=20 > One specific point at the moment: Section 7.2.5 of > draft-ietf-ipv6-2461bis-03.txt reads: >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happen: If the > advertisement were solicited, the state is changed to REACHABLE. > Otherwise, the state is set to STALE. Note that the=20 > Override flag is > ignored if the entry is in the > INCOMPLETE state. >=20 > From this paragraph, the "two things" would be: >=20 > 1. If the advertisement were solicited, the state is changed to > REACHABLE. > 2. Otherwise, the state is set to STALE. >=20 > On the other hand, the corresponding part of RFC2461 was: >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happens. If the > link layer has addresses and no Target Link-Layer address=20 > option is > included, the receiving node SHOULD silently discard the received > advertisement. Otherwise, the receiving node performs=20 > the following > steps: > (....) >=20 > From this paragraph, the "two things" would be: >=20 > 1. If the link layer has addresses and no Target Link-Layer address > option is included, the receiving node SHOULD silently discard > the received advertisement. > 2. Otherwise, the receiving node performs the following steps: > (....) >=20 > So, while the beginning part is exactly the same, the "two things" > seem to refer to completely different things. >=20 > The difference itself is not necessarily a problem. However, > rfc2461bis-03 then repeats its "two things": >=20 > - If the advertisement's Solicited flag is set, the state of the > entry is set to REACHABLE, otherwise it is set to STALE. >=20 > Now this make me really confused... >=20 > Additionally, the relationship between the two parts beginning with > "If the (target's) Neighbor Cache entry is in the INCOMPLETE=20 > state" is > not very clear to me: >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happen: (...) >=20 > If the Neighbor Cache entry is in INCOMPLETE state, the receiving > node performs the following steps: > (...) >=20 > Note that the second part was one of the "two things" in original > RFC2461. >=20 > All of these things just confused me about what this part wanted to > convey. >=20 > So, again, I'd first like to know the intent of the change, and then > I'm willing to suggest explicit text according to the intent. >=20 > I hope this time I'm clear enough. Thanks, >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Wed May 25 22:32:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8Ai-0005y1-AD; Wed, 25 May 2005 22:32:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8Ag-0005xq-4K for ipv6@megatron.ietf.org; Wed, 25 May 2005 22:32:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24200 for ; Wed, 25 May 2005 22:32:28 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db8T9-0002rw-0h for ipv6@ietf.org; Wed, 25 May 2005 22:51:37 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id DE065B3; Wed, 25 May 2005 22:32:14 -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, 25 May 2005 22:32:14 -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, 25 May 2005 22:32:12 -0400 Message-ID: <936A4045C332714F975800409DE092404A1275@tayexc14.americas.cpqcorp.net> Thread-Topic: 6LSA Slides and QoS Thread-Index: AcVhJUjkYljD60+SRUy06AUKFxSPZQAcpmGA From: "Bound, Jim" To: "Brian E Carpenter" X-OriginalArrivalTime: 26 May 2005 02:32:14.0820 (UTC) FILETIME=[20CF2A40:01C5619B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 6LSA Slides and QoS 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 Brian, explanation below. This is why we believe this decent technical work needs review to further work on good input like yours and your review. This can be a means to use the IPv6 Flow Label in a very positive way for deployment.=20 > Jim, you've stated that 6LSA respects the RFC 3697 requirement > to deliver the original, unmodified flow label. Yes and the 6LSA archtitecture will support that, what we defined in draft-chakravorty-bcc-fec-00.txt initially is that the Flow Label will be zero from clients or forwarded to 6LSR. Clearly that will change, from the client, and even from edge routers that are not 6LSA-capable. More below.=20 >=20 > draft-chakravorty-6lsa-01.txt makes that statement but does not > define any mechanism to explain how it's done. As far as I can see, > the ingress 6LSA router would have to signal downstream, and the > egress 6LSA router would have to keep state. That is correct. There are many methods to do that when the packet comes into the ingress 6LSR (6LSA Router). It also can be optimized to the egress 6LSR router to the destination router or client. Using in this draft FEC of flow label zero assumption also permitted a fast protototype and there is an implementation and I hope we can test it on Moonv6 in the near future to debug. It also permits review of the basic model and architecture before we decide on best way to move non zero flow labels. >=20 > The mystery is solved in draft-chakravorty-bcc-fec-00.txt,=20 > where I find: >=20 > > Because of the requirement to maintain the integrity of the Flow > > Label field, the 6LSA switching technique can only be applied to > > packets arriving at an edge port with their Flow Label=20 > field set to > > zero. In future work on 6LSA, more generalized=20 > treatment of packets > > that arrive with non-zero Flow Label will be presented.=20 >=20 > In other words, 6LSA as defined today is incapable of delivering the > original flow label except for default traffic. That seems like > a substantial limitation. The FEC structures and methods are defined today initially assuming this limitation not the 6LSA architecture. >From the 6LSA arch draft: draft-chakravorty-6lsa-01 > All lead packets, whether they are the first packet from the upstream > router or 6LSR or not, are treated like they were the first packet of > the flow. > Lead packet has no existing entry in the switching table of the 6LSR. > All lead packets have a 0 (zero) label coming into the 6LSA nodes > from a best-effort network. When source nodes are 6LSA nodes, lead > packets may carry non-zero labels. Conversely, hosts generating non-zero labeled packets have to work within the 6LSA domain. And we thought that it was clear to everyone that that 6LSA is the working paradigm. If one forces a non-6LSA paradigm and starts labeling the packets outside of the 6LSA network, then one needs to use the label distribution mechanism all across multiple network domains (that even MPLS does not do) and avoid using locally generated label model (one of the models we will propose) to avoid the very remote possibility of finding packets in a different flow with a duplicate label arriving with the same source address and through the same router port going to the same destination address. But, the key is we have to move non zero flow label packets as you suggest to the 6LSA egress router. =20 6LSA also want to have a very robust security method for packets that enter the 6LSA domain. That is work in progress too. The model of 6LSA is we can extend it to where we need it to go as architecture and it will support client-to-client flows restored is the objective. If we can get our collegues in the community to work on this we believe we can build a significant added value TE and QoS method here that will truly differentiate IPv6 capabilities on a network path, where IPv4 simply cannot accomplish. Also we are only working on IPv6. This model is not bogged down by any weight with any assumptions to support IPv4, thus, the model is free to evolve and execute based on what we can develop with IPv6. Thanks for jumping in here Brian we appreciate it and we need more review and the community work on this with the draft authors. /jim >=20 > Brian >=20 > Bound, Jim wrote: > > You can see good example of 6LSA in Charts at: > >=20 > >=20 > http://www.nav6tf.org/documents/arin-nav6tf-apr05/5.QoS_and_IP > v6_SC.pdf > >=20 > > The rest of the slides for IPv6 may be interesting to some from this > > joint ARIN+NAv6TF meeting too. > >=20 > > http://www.nav6tf.org/html/nav6tf_events.html > >=20 > > /jim > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 >=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 Wed May 25 22:38:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8GN-0007aG-W0; Wed, 25 May 2005 22:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8GK-0007a1-J8 for ipv6@megatron.ietf.org; Wed, 25 May 2005 22:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24797 for ; Wed, 25 May 2005 22:38:18 -0400 (EDT) Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db8Yp-00033Z-84 for ipv6@ietf.org; Wed, 25 May 2005 22:57:28 -0400 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOPQ26OBOE975XMD@vaxc.its.monash.edu.au> for ipv6@ietf.org; Thu, 26 May 2005 12:38:14 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6525980003; Thu, 26 May 2005 12:38:13 +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 41A773C006; Thu, 26 May 2005 12:38:13 +1000 (EST) Date: Thu, 26 May 2005 12:38:11 +1000 From: Greg Daley In-reply-to: <200505260103.j4Q13kX6004739@cichlid.raleigh.ibm.com> To: Thomas Narten Message-id: <42953693.7030707@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: <200505260103.j4Q13kX6004739@cichlid.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' to Proposed Standard 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 Thomas, Thomas Narten wrote: [cut] > BTW, what I meant to say above was more like: > > This document requires that an implementation do things that may > logically (if you follow the conceptual sending model) be hard to > do, because the information needed to do something may not be > available at that point in the algorithm (implementation). I.e., one > ends up having to have access to the ND cache info while doing steps > that (previously) were logically completely separate from the ND > cache. I wonder if in practice, these might be "difficult" for some > implementations. I guess that's a fair comment. There's more required knowledge in order to control operations within the NC. Nick may have more comments implementation though. [cut] > > > If you only do the MUST NOT, but not the SHOULDs, what is the point of > implementing the spec? You are allowing an upper layer to use a > tentative address, yet packets from that address presumably won't be > sent until (the normal) DAD has completed, in which case, you've paid > the price of the normal DAD delay... Right? > Yes, full DAD delay is incurred in that case (for on-link destinations). As you mentioned below off-link destinations are a different case, but I guess in scope. A lot of the interest was being driven through path restoration mechanisms like MIPv6, SCTP, etc. >>What's actually critical here is that NS's aren't sent to multicast >>addresses. They contain SLLAOs which will overwrite a peer's NCE >>destructively. > > >>So my question is: Is your problem mainly with the SHOULDs or the >>MUST NOT? > > > Am I understanding correctly that not implementing the SHOULD > effectively negates the benefits of implementing the spec? It reduces the applicability to only off-link destinations available through a discoverable router. Do you think that the draft needs a statement about the effect of not implementing the 'send to router' mechanism? > Well, maybe it depends also on what one expects the first packets to > be that a node sends. I.e., if they are for non-neighbors (i.e., > off-link) and would go through the router, then that traffic would get > sent immediately. But it appears that at least when sending to > neighbors, not implementing the SHOULDs results in no reduction in > delay. Since the implicit goal of Opti-DAD was not to create long-lasting state on neighbours, I guess the idea of delaying was seen as preferable in this case to destruction of existing NCEs. I guess that delay reduction was the main reason for having these ideas as SHOULDs. If there was a way of explicitly removing peer NCEs created during the optimistic period, then it would be good to be able to send multicast NS's, instead of forwarding to a router (or delaying). This may be difficult in practice too though (more difficult than forwarding to a router??). Greg. P.S. Here's an example of the type of mechanism which may offer an alternative and only needs to check the optimistic state from the NCE during ND operations (rather than during packet delivery). It's a lot more work than 'send to the router', though. I'd guess one way to address resolution is to send multicast NS's to neighbours, but to not reply to unicast/PROBE NS's sent from these neighbours until the end of the optimistic period. The NS created STALE entry transits immediately to DELAY upon unicast NA transmission back to the Optimistic Node. The DELAY of 5 seconds could potentially push the probe back until the node was either finished being optimistic, or discovered that it was a duplicate address. In the duplicate case, there would be about 14 seconds of delay and probing before the NCEs were deleted, along with any queued data (about 9 seconds of which would be lost?). It would require further data (and perhaps upper layer timeout) to reinitialize the NCE to the original owner's MAC address. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 23:00:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8c3-0003cY-Jh; Wed, 25 May 2005 23:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db8c1-0003cO-Ln for ipv6@megatron.ietf.org; Wed, 25 May 2005 23:00:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28331 for ; Wed, 25 May 2005 23:00:43 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db8uW-0003lH-PP for ipv6@ietf.org; Wed, 25 May 2005 23:19:53 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:1db7:2189:3231:e775]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 363C415218; Thu, 26 May 2005 12:03:19 +0900 (JST) Date: Thu, 26 May 2005 12:01:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: c54bc2f42d02429833c0ca4b8725abd7 Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 25 May 2005 22:17:19 -0400, >>>>> "Soliman, Hesham" said: > This section was changed based on comments from Pekka and yourself. Note that > I'm referring to the section as a whole and not only the first paragraph. I don't remember > the intent of changing every line since I changed the whole section in rev 2. But > the main reason for the change was clarifications and no substantial change was made. The only comments I made for this section (except the very recent one we are now discussing) were the latter part of the section. More specifically, I agreed with Pekka that the latter part contained a redundant condition, and also suggested to clarify the complex conditions in the latter part. On the other hand, I didn't even expect a change (from RFC2461) to the first part. Actually, I didn't understand the points of the changes to the first part from RFC2461 and asked the intent, rather than suggested any changes from RFC2461. That said, I'm even happy with the original text of RFC2461 about the first part of this section. (I actually said that before, see http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html) As a meta-level comment, if we cannot remember the specific reason for revising the text, I don't think it's a good idea to revise that (since it can even introduce a new bug that was not in the original document). At least I don't see any problem in the first part of this section in original RFC2461, so I'd now rather suggest to leave it (the first part of 7.2.5) as was in original RFC2461. Finally, I also noticed that Pekka's comment was not really applied in draft-ietf-ipv6-2461bis-03.txt. Specifically, the current text is different from what I proposed in the following message: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04819.html (you seemed to agree with the change: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04822.html) That is, I proposed the following text: II. If the Override flag is set, or the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: but rfc2461bis-03 actually reads: II. If the Override flag is set, or the supplied Override flag is Clear, or the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: This is clearly incorrect (the condition is then always true, since it says, "If A, or !A, or ..." (where A = the Override flag is set)) How I'd like to propose a complete suggestion. The point is: - don't change the first of section 7.2.5 from RFC2461 - address Pekka's point correctly Then the entire section would then be as follows. Is this okay for you? 7.2.5. Receipt of Neighbor Advertisements When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. Once the appropriate Neighbor Cache entry has been located, the specific actions taken depend on the state of the Neighbor Cache entry, the flags in the advertisement and the actual link-layer address supplied. If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. Otherwise, the receiving node performs the following steps: - It records the link-layer address in the Neighbor Cache entry. - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. - It sets the IsRouter flag in the cache entry based on the Router flag in the received advertisement. - It sends any packets queued for the neighbor awaiting address resolution. Note that the Override flag is ignored if the entry is in the INCOMPLETE state. If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the following actions take place: I. If the Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: a. If the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way. b. Otherwise, the received advertisement should be ignored and MUST NOT update the cache. II. If the Override flag is set, or the supplied link-layer address is the same as that in the cache, or no Target Link-layer address option was supplied, the received advertisement MUST update the Neighbor Cache entry as follows: - The link-layer address in the Target Link-Layer Address option MUST be inserted in the cache (if one is supplied and is different than the already recorded address). - If the Solicited flag is set, the state of the entry MUST be set to REACHABLE. If the Solicited flag is zero and the link-layer address was updated with a different address the state MUST be set to STALE. Otherwise, the entry's state remains unchanged. An advertisement's Solicited flag should only be set if the advertisement is a response to a Neighbor Solicitation. Because Neighbor Unreachability Detection Solicitations are sent to the cached link-layer address, receipt of a solicited advertisement indicates that the forward path is working. Receipt of an unsolicited advertisement, however, suggests that a neighbor has urgent information to announce (e.g., a changed link-layer address). If the urgent information indicates a change from what a node is currently using, the node should verify the reachability of the (new) path when it sends the next packet. There is no need to update the state for unsolicited advertisements that do not change the contents of the cache. - The IsRouter flag in the cache entry MUST be set based on the Router flag in the received advertisement. In those cases where the IsRouter flag changes from TRUE to FALSE as a result of this update, the node MUST remove that router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a router as specified in Section 7.3.3. This is needed to detect when a node that is used as a router stops forwarding packets due to being configured as a host. The above rules ensure that the cache is updated either when the Neighbor Advertisement takes precedence (i.e., the Override flag is set) or when the Neighbor Advertisement refers to the same link-layer address that is currently recorded in the cache. If none of the above apply, the advertisement prompts future Neighbor Unreachability Detection (if it is not already in progress) by changing the state in the cache entry. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed May 25 23:31:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db95v-0000RZ-Iq; Wed, 25 May 2005 23:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db95s-0000RT-4J for ipv6@megatron.ietf.org; Wed, 25 May 2005 23:31:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00509 for ; Wed, 25 May 2005 23:31:33 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db9ON-0004PA-Ra for ipv6@ietf.org; Wed, 25 May 2005 23:50:44 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 May 2005 23:31:26 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2005 23:31:24 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVhn3bzzS4MhJ0fTm+Tb0wxhnCvMwAA4xRQ From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 May 2005 03:31:26.0388 (UTC) FILETIME=[65B56F40:01C561A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis update 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 only comments I made for this section (except the very recent one > we are now discussing) were the latter part of the section. More > specifically, I agreed with Pekka that the latter part contained a > redundant condition, and also suggested to clarify the complex > conditions in the latter part. On the other hand, I didn't even > expect a change (from RFC2461) to the first part. Actually, I didn't > understand the points of the changes to the first part from RFC2461 > and asked the intent, rather than suggested any changes from RFC2461. > That said, I'm even happy with the original text of RFC2461 about the > first part of this section. (I actually said that before, see > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html) >=20 > As a meta-level comment, if we cannot remember the specific=20 > reason for > revising the text, I don't think it's a good idea to revise that > (since it can even introduce a new bug that was not in the original > document). >=20 > At least I don't see any problem in the first part of this section in > original RFC2461, so I'd now rather suggest to leave it (the first > part of 7.2.5) as was in original RFC2461. >=20 > Finally, I also noticed that Pekka's comment was not really=20 > applied in > draft-ietf-ipv6-2461bis-03.txt. Specifically, the current text is > different from what I proposed in the following message: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04819.html > (you seemed to agree with the change: > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04822.html) >=20 > That is, I proposed the following text: >=20 > II. If the Override flag is set, or the supplied=20 > link-layer address > e is the same as that in the cache, or no Target=20 > Link-layer address > option was supplied, the received advertisement MUST update the > Neighbor Cache entry as follows: >=20 > but rfc2461bis-03 actually reads: >=20 > II. If the Override flag is set, or the supplied Override flag is > Clear, or the supplied link-layer address is the same=20 > as that in > the cache, or no Target Link-layer address option was=20 > supplied, > the received advertisement MUST update the Neighbor=20 > Cache entry > as follows: =3D> Yes this is clearly wrong. I'll update this. As for the rest, you = still don't say what's wrong with it, you just ask for it to be changed back. I don't = agree with your suggestion because there is no basis for it, but to save = cycles I'll change it back... Hesham >=20 > This is clearly incorrect (the condition is then always=20 > true, since it > says, "If A, or !A, or ..." (where A =3D the Override flag is set)) >=20 > How I'd like to propose a complete suggestion. The point is: >=20 > - don't change the first of section 7.2.5 from RFC2461 > - address Pekka's point correctly >=20 > Then the entire section would then be as follows. Is this okay for > you? >=20 > 7.2.5. Receipt of Neighbor Advertisements >=20 > When a valid Neighbor Advertisement is received (either=20 > solicited or > unsolicited), the Neighbor Cache is searched for the=20 > target's entry. > If no entry exists, the advertisement SHOULD be silently=20 > discarded. > There is no need to create an entry if none exists, since the > recipient has apparently not initiated any communication with the > target. >=20 > Once the appropriate Neighbor Cache entry has been located, the > specific actions taken depend on the state of the Neighbor Cache > entry, the flags in the advertisement and the actual link-layer > address supplied. >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happens. If the > link layer has addresses and no Target Link-Layer address=20 > option is > included, the receiving node SHOULD silently discard the received > advertisement. Otherwise, the receiving node performs=20 > the following > steps: >=20 > - It records the link-layer address in the Neighbor Cache entry. >=20 > - If the advertisement's Solicited flag is set, the state of the > entry is set to REACHABLE, otherwise it is set to STALE. >=20 > - It sets the IsRouter flag in the cache entry based on=20 > the Router > flag in the received advertisement. >=20 > - It sends any packets queued for the neighbor awaiting address > resolution. >=20 > Note that the Override flag is ignored if the entry is in the > INCOMPLETE state. >=20 > If the target's Neighbor Cache entry is in any state other than > INCOMPLETE when the advertisement is received, the=20 > following actions > take place: >=20 > I. If the Override flag is clear and the supplied=20 > link-layer address > differs from that in the cache, then one of two actions takes > place: > a. If the state of the entry is REACHABLE, set it to STALE, but > do not update the entry in any other way. > b. Otherwise, the received advertisement should be=20 > ignored and MUST > NOT update the cache. > II. If the Override flag is set, or the supplied=20 > link-layer address > is the same as that in the cache, or no Target=20 > Link-layer address > option was supplied, the received advertisement MUST update the > Neighbor Cache entry as follows: >=20 > - The link-layer address in the Target Link-Layer Address option > MUST be inserted in the cache (if one is supplied and=20 > is different > than the already recorded address). >=20 > - If the Solicited flag is set, the state of the entry=20 > MUST be set > to REACHABLE. If the Solicited flag is zero and the link-layer > address was updated with a different address the state=20 > MUST be set > to STALE. Otherwise, the entry's state remains unchanged. >=20 > An advertisement's Solicited flag should only be set if the > advertisement is a response to a Neighbor=20 > Solicitation. Because > Neighbor Unreachability Detection Solicitations are sent to the > cached link-layer address, receipt of a solicited advertisement > indicates that the forward path is working. Receipt of an > unsolicited advertisement, however, suggests that a=20 > neighbor has > urgent information to announce (e.g., a changed link-layer > address). If the urgent information indicates a=20 > change from what > a node is currently using, the node should verify the=20 > reachability > of the (new) path when it sends the next packet. =20 > There is no need > to update the state for unsolicited advertisements that do not > change the contents of the cache. >=20 > - The IsRouter flag in the cache entry MUST be set based on the > Router flag in the received advertisement. In those=20 > cases where > the IsRouter flag changes from TRUE to FALSE as a=20 > result of this > update, the node MUST remove that router from the=20 > Default Router > List and update the Destination Cache entries for all=20 > destinations > using that neighbor as a router as specified in Section 7.3.3. > This is needed to detect when a node that is used as a router > stops forwarding packets due to being configured as a host. >=20 > The above rules ensure that the cache is updated either when the > Neighbor Advertisement takes precedence (i.e., the=20 > Override flag is > set) or when the Neighbor Advertisement refers to the=20 > same link-layer > address that is currently recorded in the cache. If none of the > above apply, the advertisement prompts future Neighbor=20 > Unreachability > Detection (if it is not already in progress) by changing=20 > the state in > the cache entry. >=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 Thu May 26 00:16:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db9nV-0007rx-0v; Thu, 26 May 2005 00:16:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db9nS-0007rs-In for ipv6@megatron.ietf.org; Thu, 26 May 2005 00:16:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03017 for ; Thu, 26 May 2005 00:16:35 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbA5x-0005Sw-Pp for ipv6@ietf.org; Thu, 26 May 2005 00:35:47 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 32DD015218; Thu, 26 May 2005 13:19:12 +0900 (JST) Date: Thu, 26 May 2005 13:17:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: 7aafa0432175920a4b3e118e16c5cb64 Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 25 May 2005 23:31:24 -0400, >>>>> "Soliman, Hesham" said: > => Yes this is clearly wrong. I'll update this. As for the rest, you still don't say > what's wrong with it, you just ask for it to be changed back. I don't agree > with your suggestion because there is no basis for it, but to save cycles I'll > change it back... Sorry if I've been keeping unclear, but regarding the "rest", my point is that the current text (of the first part of Section 7.2.5) in 2461bis is more confusing than RFC2461, and I actually didn't see any problem in the original text of RFC2461 (and, for that matter, no one knows the rationale of the changes in 2461bis). That's why I suggested to change it back. Assuming (the first part of) 2461bis is more confusing than RFC2461, I believe this is a reasonable suggestion (isn't it?). Regarding whether (the first part of) 2461bis is more confusing than RFC2461, I admit "confusing" is a subjective word and opinions may vary. However, as I pointed out in this thread, at least the duplicate description in 2461bis is clearly confusing to me. That is, If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happen: If the advertisement were solicited, the state is changed to REACHABLE. Otherwise, the state is set to STALE. Note that the Override flag is ignored if the entry is in the INCOMPLETE state. If the Neighbor Cache entry is in INCOMPLETE state, the receiving node performs the following steps: (...) - If the advertisement's Solicited flag is set, the state of the entry is set to REACHABLE, otherwise it is set to STALE. (The bullet is actually already covered in the paragraph starting with "If the target's...") Is it so unclear to say it's confusing to have the duplicate description? Is it strange to wonder whether we can unify the duplicate part, and, e.g., remove the redundant paragraph (with moving the "Note" sentence into the bullet if necessary)? I'm sorry if I just look behaving in a stubborn way, blocking the document...but please believe me, I just want 2461bis to be clearer. I hope this message expresses my point clearly. 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 May 26 00:45:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbAFS-00044e-I3; Thu, 26 May 2005 00:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbAFN-00044V-Nx for ipv6@megatron.ietf.org; Thu, 26 May 2005 00:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04678 for ; Thu, 26 May 2005 00:45:26 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbAXu-00066P-Ba for ipv6@ietf.org; Thu, 26 May 2005 01:04:38 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 May 2005 00:45:20 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2005 00:45:18 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVhqbSw8UdOQwpPQ+Kqx2W7iahYXwAA569w From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 May 2005 04:45:20.0513 (UTC) FILETIME=[B8A73710:01C561AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis update 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 No problem, I don't think you're trying to block anything. Please = continue to=20 provide comments on the doc, I appreciate it. I think what happened was = that I=20 assumed you were ok with the change since Peter said he was fine and I = interpreted your last response on that thread to be that you mainly wanted to see Peter's = comment addressed.=20 The new version will be submitted on Friday so if there are more = comments please let me know. thx, Hesham > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp=20 > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Thursday, May 26, 2005 12:17 AM > To: Soliman, Hesham > Cc: ipv6@ietf.org > Subject: Re: 2461bis update >=20 >=20 > >>>>> On Wed, 25 May 2005 23:31:24 -0400,=20 > >>>>> "Soliman, Hesham" said: >=20 > > =3D> Yes this is clearly wrong. I'll update this. As for the=20 > rest, you still don't say > > what's wrong with it, you just ask for it to be changed=20 > back. I don't agree > > with your suggestion because there is no basis for it, but=20 > to save cycles I'll > > change it back... >=20 > Sorry if I've been keeping unclear, but regarding the=20 > "rest", my point > is that the current text (of the first part of Section 7.2.5) in > 2461bis is more confusing than RFC2461, and I actually didn't see any > problem in the original text of RFC2461 (and, for that matter, no one > knows the rationale of the changes in 2461bis). That's why I > suggested to change it back. Assuming (the first part of) 2461bis is > more confusing than RFC2461, I believe this is a reasonable=20 > suggestion > (isn't it?). >=20 > Regarding whether (the first part of) 2461bis is more confusing than > RFC2461, I admit "confusing" is a subjective word and opinions may > vary. However, as I pointed out in this thread, at least the > duplicate description in 2461bis is clearly confusing to me.=20 > That is, >=20 > If the target's Neighbor Cache entry is in the INCOMPLETE=20 > state when > the advertisement is received, one of two things happen: If the > advertisement were solicited, the state is changed to REACHABLE. > Otherwise, the state is set to STALE. Note that the=20 > Override flag is > ignored if the entry is in the > INCOMPLETE state. >=20 > If the Neighbor Cache entry is in INCOMPLETE state, the receiving > node performs the following steps: >=20 > (...) >=20 > - If the advertisement's Solicited flag is set, the state of the > entry is set to REACHABLE, otherwise it is set to STALE. >=20 > (The bullet is actually already covered in the paragraph=20 > starting with > "If the target's...") >=20 > Is it so unclear to say it's confusing to have the duplicate > description? Is it strange to wonder whether we can unify the > duplicate part, and, e.g., remove the redundant paragraph=20 > (with moving > the "Note" sentence into the bullet if necessary)? >=20 > I'm sorry if I just look behaving in a stubborn way, blocking the > document...but please believe me, I just want 2461bis to be clearer. >=20 > I hope this message expresses my point clearly. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Thu May 26 02:05:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbBV2-00080w-VA; Thu, 26 May 2005 02:05:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dazqh-0005Zj-1f; Wed, 25 May 2005 13:39:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03585; Wed, 25 May 2005 13:39:16 -0400 (EDT) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db096-0003xl-Pc; Wed, 25 May 2005 13:58:22 -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, 25 May 2005 13:38:51 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7309CB45@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVhHmGDmhPx71eeTiSg0e2QoYJwKAAMSD8A From: "Woundy, Richard" To: "Iljitsch van Beijnum" , "Thomas Narten" X-OriginalArrivalTime: 25 May 2005 17:38:52.0578 (UTC) FILETIME=[9DFC9020:01C56150] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 26 May 2005 02:05:43 -0400 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit 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 of this, coupled with the fact that, AFAIK, no OS implements DHCPv6, means that there is essentially zero experience with DHCPv6 in the operational community. This means that at this time, there is little point in asking the operational community what should happen with the M and O bits. Or perhaps this could be the ideal time to ask the operational community what should happen with the M and O bits -- before software developers go too far down a particular direction without operator guidance? Some of us operators do more than just configure and test vendor products. -- Rich -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum Sent: Wednesday, May 25, 2005 5:43 AM To: Thomas Narten Cc: dhcwg@ietf.org; IETF IPv6 Mailing List Subject: [dhcwg] Re: purpose of m/o bit [Crossposted to dhcwg even though I'm not on that list, as people =20 there may be able to add some useful insights.] On 24-mei-2005, at 16:45, Thomas Narten wrote: > I wonder if there is key question here that the community has simply=20 > not agreed on (yet), and that that question is at the heart of all=20 > this "confusion". > Does the community feel that operators need RA bits that=20 > control/indicate whether a client is to invoke DHC? That is, is there=20 > a need for the sys admin to signal to client whether DHC is to be=20 > invoked? By a strange coincidence, I spent most of the day yesterday taking =20 several DHCPv6 implementations for a test drive, for reasons =20 unrelated to this discussion. These implementations are: KAME DHCP6, the unnamed Linux fork of the =20 KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco =20 IOS implemenation. Conclusion: the Cisco implementation is incomplete (no address =20 assignment) and the other two are too immature to be of much use. I'm impressed with the prefix delegation functionality, but as =20 before, the prospect of running such a complex protocol just to =20 optain a domain search list and some DNS resolvers makes me very =20 uncomfortable. All of this, coupled with the fact that, AFAIK, no OS implements =20 DHCPv6, means that there is essentially zero experience with DHCPv6 =20 in the operational community. This means that at this time, there is =20 little point in asking the operational community what should happen =20 with the M and O bits. In other words: this is not the time declare the bits useless and =20 remove them. > Second, is it important that such a signal be honored by clients?=20 > (That is, if clients end up mostly ignoring the flags, does their=20 > presence become useless?) Depends. There are three possible ways this can play out: - the DNS resolver issue is solved in a way that doesn't requite =20 DHCP, so most people don't don't run DHCPv6 at all, others run it all =20 the time -> no bits necessary - the DNS resolver issue isn't solved in another way, so everyone =20 runs some form of DHCPv6 all the time -> no bits necessary - DHCP provides benefits but some people are reluctant to use it -> =20 helpful to know whether to bother running DHCPv6 > For example, should the sys admin be able to say "do not run DHC,=20 > doing so wastes local resources and won't get you any config info"?=20 > (And should that be honored by clients?) I think it's good to recognize that in the past, there have often =20 been security issues with non-text based UDP protocols, so knowing =20 there is no need to run DHCP and then not running it would be good =20 security. > Fundamentally, it is only the access network that has knowledge of=20 > whether running DHC is useful. Thus, by default, clients (arguably)=20 > can't know whether running DHC is useful, so by default they shold=20 > invoke DHC (unless the sys admin signals "don't invoke DHC"). > Or (switching the argument), by default, client should not invoke DHC, > unless the local sys admin indicates doing so is appropriate. There isn't really a difference here, except for what happens when =20 there are no RAs. I would be interested in hearing viewpoints on the usefulness of =20 running DHCPv6 even though the hints indicate that there is no need to. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 26 02:05:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbBV4-00081N-Cf; Thu, 26 May 2005 02:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db2lg-0000wF-CK; Wed, 25 May 2005 16:46:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27950; Wed, 25 May 2005 16:46:18 -0400 (EDT) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db346-00030a-Us; Wed, 25 May 2005 17:05:24 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.11138753; Wed, 25 May 2005 16:45:47 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 May 2005 16:45:42 -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, 25 May 2005 16:45:41 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7309CB4D@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVhHmGDmhPx71eeTiSg0e2QoYJwKAAMSD8AAADP6CAAAR8RIA== From: "Woundy, Richard" To: "Bernie Volz \(volz\)" , "Iljitsch van Beijnum" , "Thomas Narten" X-OriginalArrivalTime: 25 May 2005 20:45:42.0295 (UTC) FILETIME=[B77FA270:01C5616A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 26 May 2005 02:05:43 -0400 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit 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 Folks, I can't speak on behalf of all cable operators, but I can provide my own current perspective on IPv6 and the M/O flags. There are three primary types of DHCPv4 clients in cable networks today: cable modems, functional entities co-resident with the cable modems (such as PacketCable MTA VoIP endpoints, CableHome gateways, etc.), and customer computers and other customer-controlled equipment. For our business, we want the ability to control which prefixes were assigned to which customer devices. For example, we may want to assign different prefixes to devices corresponding to non-customers and to "not-yet-customers" (those that will self-provision their service). Our current plans are that cable modems and co-resident functional entities would use DHCPv6 for stateful address configuration as part of their own boot process. DHCPv6 would also provide information for configuration downloads, time servers, and domain name servers (as needed). I don't think we would want to use address autoconfiguration for those devices/entities. Customer computers and other customer equipment tend to be a little trickier, since such devices may be used in different service provider contexts (e.g. wireless, where bandwidth is much more precious than in cable), and since OS developers don't always worry about service provider network requirements (especially if they are focused on personal computing or enterprise network/IT requirements first). One possible approach is that cable modems (or some subset of cable modems) would use DHCPv6 prefix delegation (PD) to get a customer-specific prefix, which could be learned by customer computers through address autoconfiguration (e.g. the cable modem would become an IPv6 router). The customer computers could use DHCPv6 (ala RFC 3736) to obtain additional parameters (e.g. domain name servers), but DHCPv6 use would be optional for network access. This plan presumes that PD scales for our customer base, which today is largely residential broadband customers. The other approach is that each customer computer would use DHCPv6 for stateful address configuration. This matches our current IPv4 deployment model where every customer computer is a DHCPv4 client of our DHCP servers. But this approach would mandate DHCPv6 use for network access, which may be fairly painful when there are few/no DHCPv6 client implementations in OS's today. :^( What does that mean for the M/O flags discussion? I suspect we might try to deploy both approaches for customer computer address allocation, which would imply that we would want to use something like the M/O flags to signal to customer computers when DHCPv6 is necessary for network access, and when it is not. While we expect cable modems to use DHCPv6 exclusively, I have heard of other cable operators that want to experiment with address autoconfig for cable modems -- although to be honest I am not really sure how that would work. I would think it is our responsibility (as service providers) to set the M/O flag settings correctly and appropriately on our edge routers (CMTSs). Hope this perspective helps. -- Rich -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, May 25, 2005 1:55 PM To: Woundy, Richard; Iljitsch van Beijnum; Thomas Narten Cc: dhcwg@ietf.org; IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit So Rich, I'll ask. What would you like to see happen? - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Woundy, Richard > Sent: Wednesday, May 25, 2005 1:39 PM > To: Iljitsch van Beijnum; Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: RE: [dhcwg] Re: purpose of m/o bit >=20 > >All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 in > the operational community. This means that at this time, there is=20 > little point in asking the operational community what should happen > with the M > and O bits. >=20 > Or perhaps this could be the ideal time to ask the > operational community > what should happen with the M and O bits -- before software developers > go too far down a particular direction without operator guidance? >=20 > Some of us operators do more than just configure and test vendor=20 > products. >=20 > -- Rich >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf > Of Iljitsch van Beijnum > Sent: Wednesday, May 25, 2005 5:43 AM > To: Thomas Narten > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit >=20 >=20 > [Crossposted to dhcwg even though I'm not on that list, as people > there may be able to add some useful insights.] >=20 > On 24-mei-2005, at 16:45, Thomas Narten wrote: >=20 > > I wonder if there is key question here that the community > has simply > > not agreed on (yet), and that that question is at the heart of all > > this "confusion". >=20 > > Does the community feel that operators need RA bits that > > control/indicate whether a client is to invoke DHC? That=20 > is, is there > > a need for the sys admin to signal to client whether DHC is to be > > invoked? >=20 > By a strange coincidence, I spent most of the day yesterday taking > several DHCPv6 implementations for a test drive, for reasons =20 > unrelated to this discussion. >=20 > These implementations are: KAME DHCP6, the unnamed Linux fork of the > KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco =20 > IOS implemenation. >=20 > Conclusion: the Cisco implementation is incomplete (no address > assignment) and the other two are too immature to be of much use. >=20 > I'm impressed with the prefix delegation functionality, but as > before, the prospect of running such a complex protocol just to =20 > optain a domain search list and some DNS resolvers makes me very =20 > uncomfortable. >=20 > All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 =20 > in the operational community. This means that at this time, there is =20 > little point in asking the operational community what should happen =20 > with the M and O bits. >=20 > In other words: this is not the time declare the bits useless and > remove them. >=20 > > Second, is it important that such a signal be honored by clients? > > (That is, if clients end up mostly ignoring the flags, does their=20 > > presence become useless?) >=20 > Depends. There are three possible ways this can play out: >=20 > - the DNS resolver issue is solved in a way that doesn't requite > DHCP, so most people don't don't run DHCPv6 at all, others=20 > run it all =20 > the time -> no bits necessary > - the DNS resolver issue isn't solved in another way, so everyone =20 > runs some form of DHCPv6 all the time -> no bits necessary > - DHCP provides benefits but some people are reluctant to use it -> =20 > helpful to know whether to bother running DHCPv6 >=20 > > For example, should the sys admin be able to say "do not run DHC, > > doing so wastes local resources and won't get you any config info"?=20 > > (And should that be honored by clients?) >=20 > I think it's good to recognize that in the past, there have often > been security issues with non-text based UDP protocols, so knowing =20 > there is no need to run DHCP and then not running it would be good =20 > security. >=20 > > Fundamentally, it is only the access network that has knowledge of > > whether running DHC is useful. Thus, by default, clients (arguably)=20 > > can't know whether running DHC is useful, so by default they shold=20 > > invoke DHC (unless the sys admin signals "don't invoke DHC"). >=20 > > Or (switching the argument), by default, client should not > invoke DHC, >=20 > > unless the local sys admin indicates doing so is appropriate. >=20 > There isn't really a difference here, except for what happens when > there are no RAs. >=20 > I would be interested in hearing viewpoints on the usefulness of > running DHCPv6 even though the hints indicate that there is=20 > no need to. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=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 May 26 02:33:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbBvR-0004IC-AU; Thu, 26 May 2005 02:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbBvO-0004I7-Uf for ipv6@megatron.ietf.org; Thu, 26 May 2005 02:32:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02402 for ; Thu, 26 May 2005 02:32:57 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbCDv-00007I-36 for ipv6@ietf.org; Thu, 26 May 2005 02:52:08 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1567815218; Thu, 26 May 2005 15:35:31 +0900 (JST) Date: Thu, 26 May 2005 15:33:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: 00e94c813bef7832af255170dca19e36 Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 24 May 2005 10:04:25 -0400, >>>>> "Soliman, Hesham" said: > I submitted an updated revision of 2461bis which includes > the resolutions that were agreed on by the WG in the last meeting > (the SLLAO thread). It also includes fixes for the comments Tatuya > raised on the last version. I've checked the latest version of the draft with my previous comments (different ones from what we're discussing in a separate branch of this thread): http://www1.ietf.org/mail-archive/web/ipv6/current/msg04369.html Not all of them were addressed in the 03 version, but I can live with the current text for most of them. One (possibly) substantial point is comment 17, which was: > 17. APPENDIX A (MULTIHOMED HOSTS) > > [...] Under > similar conditions in the non-multihomed host case, a node > treats all destinations as residing on-link, and communication > proceeds. [...] > > This is the so-called "on-link" assumption, which was removed in > rfc2461bis. Note that we cannot simply remove this sentence, since it > would also affect the succeeding sentence. And the 03 version reads: 1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. One possible approach for a multihomed node would be to attempt to perform address resolution on all interfaces, a step involving significant complexity. I'm not sure if this really addresses the issue. Actually, isn't the "possible approach" (i.e., performing address resolution anyway, when no RA is received) just a multi-homed version of the "on-link assumption", which was removed from 2461bis? And, if so, is there any special reason for allowing the "removed" feature for the multihomed case? In the sense of the removal of the on-link assumption, perhaps the right answer is: "If no Router Advertisement is received on any interfaces, the host will simply not be able to send any packets on any link outside itself (but this is not different from the single-homed case)." The following is a summary of the comments which are not fully addressed. I don't necessarily stick to these, but it would be nice if you could check those once again. 1: does not seem to be addressed. 2: does not seem to be addressed. 3: OK, but it needs an editorial change since it includes too short a line as a result of the change. 4: the text in 03 is different from what I suggested. Although I don't push that strongly, I still believe my suggestion is better than the current text. 6: OK, but perhaps "prefix option" should be "prefix information option". (I should have pointed this out with the WGLC comments) 7: does not seem to be addressed, but I don't mind that. 11: slightly different from what I suggested. But I don't mind that. 13: does not seem to be addressed. (But the text is the same as RFC2461, and we can probably just live with that.) 16: does not seem to be addressed. 30: does not seem to be addressed, but this is probably very minor and I can lieve with the 03 text. 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 May 26 04:03:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbDL1-0002O8-RZ; Thu, 26 May 2005 04:03:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbDKy-0002Nn-CO for ipv6@megatron.ietf.org; Thu, 26 May 2005 04:03:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08712 for ; Thu, 26 May 2005 04:03:26 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbDdV-0002Cq-K4 for ipv6@ietf.org; Thu, 26 May 2005 04:22:39 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9B34F15218; Thu, 26 May 2005 17:06:02 +0900 (JST) Date: Thu, 26 May 2005 17:04:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: cab78e1e39c4b328567edb48482b6a69 Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 26 May 2005 00:45:18 -0400, >>>>> "Soliman, Hesham" said: > No problem, I don't think you're trying to block anything. Please continue to > provide comments on the doc, I appreciate it. I think what happened was that I > assumed you were ok with the change since Peter said he was fine and I interpreted your last > response on that thread to be that you mainly wanted to see Peter's comment addressed. Thanks for your patience. Hoping that you can still accept this one:-), here is one more related thing: 2461bis-03 (more accurately since 2461bis-01) has a new paragraph in Section 7.2.5: In any state, if the link layer has addresses and an unsolicited Neighbor Advertisement is received with the O flag cleared, with no Target Link-Layer address option included, the receiving node SHOULD silently discard the received advertisement. (the 3rd paragraph of this section) The corresponding part of original RFC2462 should be the following line: [If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens.] If the link layer has addresses and no Target Link-Layer address option is included, the receiving node SHOULD silently discard the received advertisement. As far as I can see, the new text is more than just a "clarification". In the new text, - the rule is applied to all neighbor cache states. (in original RFC2461, it was limited to the INCOMPLETE state) - a new condition about the O flag is added So I guess there should have been a clear reason for the new text. If it was, what was that? Or, if there was actually no special reason (or we cannot even remember that), it would be another reason for changing it back (for "safety"). 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 May 26 05:39:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbEq3-00017s-4s; Thu, 26 May 2005 05:39:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbEq1-00017m-09 for ipv6@megatron.ietf.org; Thu, 26 May 2005 05:39:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14416 for ; Thu, 26 May 2005 05:39:34 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbF8Y-0004Ai-Te for ipv6@ietf.org; Thu, 26 May 2005 05:58:48 -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 j4Q9dJi3017330 for ; Thu, 26 May 2005 10:39: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 KAA13812 for ; Thu, 26 May 2005 10:39:18 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j4Q9dIg06335 for ipv6@ietf.org; Thu, 26 May 2005 10:39:18 +0100 Date: Thu, 26 May 2005 10:39:18 +0100 From: Tim Chown To: IPv6 WG Message-ID: <20050526093918.GF4713@login.ecs.soton.ac.uk> Mail-Followup-To: IPv6 WG References: <936A4045C332714F975800409DE092404A0B57@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE092404A0B57@tayexc14.americas.cpqcorp.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: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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, May 24, 2005 at 10:44:37AM -0400, Bound, Jim wrote: > > My response below. Thus I cannot support this going to the IESG without > further discussion as my input. I also support Margaret's request for > this to be checked by RTSP persons, and I realize Dave T. clearly has > this expertise but it is a good logic check. Unless we want to remove > RSTP. I think we should include RSTP but it needs more review. This seems sensible. > I also would like to see this work not focus at all on IPv4 and only > address IPv6. The IPv4 work should be a separate document completely. > To permit this behavior for prefixes to span links in IPv6 is a > significant change to one of our architectural precepts for IPv6 and > cannot be considered lightly, regarding link behavior. An interesting point is made in the last para of 1.1, that if PD is used with an existing IPv4 ARP proxying scheme, you may get multiple IPv6 links delegated with one IPv4 subnet, and some potential complications. But I agree that a compromise for IPv6 to cater for IPv4 is a debatable issue. Also, I'm not sure that ISPs charging for multiple prefixes (whether they will or not) and the payment issue needs to be in here? As an aside, I feel the introduction is missing something (and maybe this is linked to Margaret's scoping question) - para 1 talks of "the problem" and para 2 of a "common solution" but the problem isn't stated in the main text (the abstract implies it :). -- 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 May 26 10:17:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbJAn-0003H7-US; Thu, 26 May 2005 10:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbJAm-0003H2-SG for ipv6@megatron.ietf.org; Thu, 26 May 2005 10:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01766 for ; Thu, 26 May 2005 10:17:18 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbJTL-00020c-Gh for ipv6@ietf.org; Thu, 26 May 2005 10:36:32 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 May 2005 10:17:08 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2005 10:17:06 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVhvMAB24SY/kmcShO09Gduhkf/7wAP0SPQ From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 May 2005 14:17:08.0060 (UTC) FILETIME=[998B71C0:01C561FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis update 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 > > 17. APPENDIX A (MULTIHOMED HOSTS) > > > > [...] Under > > similar conditions in the non-multihomed host case, a node > > treats all destinations as residing on-link, and=20 > communication > > proceeds. [...] > > > > This is the so-called "on-link" assumption, which was removed in > > rfc2461bis. Note that we cannot simply remove this=20 > sentence, since it > > would also affect the succeeding sentence. >=20 > And the 03 version reads: >=20 > 1) If no Router Advertisement is received on any interfaces, a > multihomed host will have no way of knowing which=20 > interface to > send packets out on, even for on-link destinations. > One possible approach for a multihomed node would be=20 > to attempt > to perform address resolution on all interfaces, a step > involving significant complexity. >=20 > I'm not sure if this really addresses the issue. Actually, isn't the > "possible approach" (i.e., performing address resolution anyway, when > no RA is received) just a multi-homed version of the "on-link > assumption", which was removed from 2461bis? And, if so, is=20 > there any > special reason for allowing the "removed" feature for the multihomed > case? >=20 =3D> I don't think it's the same as the on-link assumption. It's = suggested as one=20 possible approach and is not mandated (on top of being in the appendix), = but also,=20 it's fine to attempt address resolution because those addresses might = actually be onlink. I.e. the node does not automatically assume that the = addresses are onlink, which was the case before. We need to somehow address both = cases: a) there is no router and some of the addresses are in fact onlink, and b) = there is=20 no RA because there is no native v6 connectivity and everything should = go through=20 a tunnel. > The following is a summary of the comments which are not fully > addressed. I don't necessarily stick to these, but it would be nice > if you could check those once again. =3D> I'll address the ones that you do mind not being addressed below. >=20 > 1: does not seem to be addressed. =3D> I took a look at it and didn't find it breaking the initial = definition in the doc. It is=20 a mix but it's not a harmful mix. If there are misleading examples = please let me know. I'll look again before sending the next rev. > 2: does not seem to be addressed. =3D> I can change this, it's not a big issue. > 3: OK, but it needs an editorial change since it includes too short a > line as a result of the change. > 4: the text in 03 is different from what I suggested. Although I > don't push that strongly, I still believe my suggestion is better > than the current text. =3D> ok. I actually don't see a problem with the current text. > 6: OK, but perhaps "prefix option" should be "prefix information > option". (I should have pointed this out with the WGLC comments) =3D> ok > 16: does not seem to be addressed. =3D> ok, will add a ref. > 30: does not seem to be addressed, but this is probably very=20 > minor and > I can lieve with the 03 text. =3D> Good. I didn't see a need to change it. Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Thu May 26 11:57:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKk6-0004GY-Qw; Thu, 26 May 2005 11:57:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbKk3-0004Fx-Aw for ipv6@megatron.ietf.org; Thu, 26 May 2005 11:57:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08180 for ; Thu, 26 May 2005 11:57:44 -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.33) id 1DbL2Y-0004HO-Hi for ipv6@ietf.org; Thu, 26 May 2005 12:17:02 -0400 Message-ID: <090901c5620b$cea3f0e0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Thomas Narten" References: <200505260103.j4Q13kX6004739@cichlid.raleigh.ibm.com> Date: Thu, 26 May 2005 08:58:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 Thomas, > > > I've reviewed this document and on the whole think it's fine for PS. > > > > > > But I do have one general concern. This document requires that an > > > implementation do what in practice, I think might be "difficult" for > > > some implementations. While that is OK at one level, I fear that some > > > implementors will do most of this spec, but not all of it. I wonder if > > > that would be a good outcome. > > BTW, what I meant to say above was more like: > > This document requires that an implementation do things that may > logically (if you follow the conceptual sending model) be hard to > do, because the information needed to do something may not be > available at that point in the algorithm (implementation). I.e., one > ends up having to have access to the ND cache info while doing steps > that (previously) were logically completely separate from the ND > cache. I wonder if in practice, these might be "difficult" for some > implementations. > To be more specific, if I understand your concern correctly, the problem is that the host is required by this to send packets to the router at a time when it does not have the router's link address? jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 26 13:10:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLs1-0001MB-D2; Thu, 26 May 2005 13:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLrv-0001Lm-Da for ipv6@megatron.ietf.org; Thu, 26 May 2005 13:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13712 for ; Thu, 26 May 2005 13:09:58 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbMAV-0006Af-Kn for ipv6@ietf.org; Thu, 26 May 2005 13:29:16 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4QH8qbf008428 for ; Thu, 26 May 2005 13:08:53 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4QH8qbY152510 for ; Thu, 26 May 2005 13:08:52 -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 j4QH8qWR022204 for ; Thu, 26 May 2005 13:08:52 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4QH8qg1022189; Thu, 26 May 2005 13:08:52 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4QH8dQN012721; Thu, 26 May 2005 13:08:51 -0400 Message-Id: <200505261708.j4QH8dQN012721@rotala.raleigh.ibm.com> To: "James Kempf" In-Reply-To: Message from kempf@docomolabs-usa.com of "Thu, 26 May 2005 08:58:42 PDT." <090901c5620b$cea3f0e0$016115ac@dcml.docomolabsusa.com> Date: Thu, 26 May 2005 13:08:39 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 > To be more specific, if I understand your concern correctly, the problem is > that the host is required by this to send packets to the router at a time > when it does not have the router's link address? Somewhat different. From an implementation perspective, one needs access to information (e.g., whether the router's link-layer address is in the cache) at a place in the implementation where that information is not necessarily readily availbale. But, looking back over the document again, I think I've convinced myself that this may not be a big issue after all. However, thinking and rereading leads me to two more thoughts: In off-list mail: Jari Arkko writes: > > * Optimistic DAD SHOULD NOT be used to configure addresses unless the > > probability of collision is exceedingly small. > I find it very hard to implement this. More guidance would be > needed. Did you mean "... SHOULD NOT when addresses have > been configured manually"? I tend to agree. Actually, I wonder if what is needed is more of an applicability statement saying what types of addresses it is appropriate to use this procedure for, and where not. For example, can optimistic DAD be used for the LL address? It took me some thinking to decide whether it could or not. The answer I believe is yes, but that is not immediately obvious, I would assert. But this all depends on having the link-layer address of a router in the cache (as had been discussed already). The second thought I have is that the security considerations section needs some more text, something along the following lines: Optimistic DAD takes steps to ensure that if another node is already using an address, the proper link-layer address in existing Neighbor Cache Entries is not replaced with the link-layer address of the Optimistic node. However, there are still scenarios where incorrect entries may be created, if only temporarily. For example, if a router (while forwarding a packet) sends out a Neighbor Solicitation for an address, the optimistic node may respond first, and if the router has no pre-existing link-layer address for that IP address, it will accept the response and (incorrectly) forward any queued packets to the optimistic node. The optimistic node may then respond in an incorrect manner (e.g., sending a TCP RST in response to an unknown TCP connection). Such transient conditions should be short-lived, in most cases. Likewise, an Optimistic node can still inject IP packets into the Internet that will in effect be "spoofed" packets appearing to come from the legitimate node. In some cases, those packets may lead to errors or other operational problems, though one would expect that upper layer protocols would generally treat such packets robustly, in the same way they must treat old and other duplicate packets. 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 May 26 13:41:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMMA-0005ie-DL; Thu, 26 May 2005 13:41:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMM8-0005iZ-Ud for ipv6@megatron.ietf.org; Thu, 26 May 2005 13:41:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16042 for ; Thu, 26 May 2005 13:41:15 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbMel-0006uX-9q for ipv6@ietf.org; Thu, 26 May 2005 14:00:32 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:1515:97d3:3b2:4455]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8783315218; Fri, 27 May 2005 02:43:51 +0900 (JST) Date: Fri, 27 May 2005 02:42:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 26 May 2005 10:17:06 -0400, >>>>> "Soliman, Hesham" said: >> And the 03 version reads: >> >> 1) If no Router Advertisement is received on any interfaces, a >> multihomed host will have no way of knowing which >> interface to >> send packets out on, even for on-link destinations. >> One possible approach for a multihomed node would be >> to attempt >> to perform address resolution on all interfaces, a step >> involving significant complexity. >> >> I'm not sure if this really addresses the issue. Actually, isn't the >> "possible approach" (i.e., performing address resolution anyway, when >> no RA is received) just a multi-homed version of the "on-link >> assumption", which was removed from 2461bis? And, if so, is >> there any >> special reason for allowing the "removed" feature for the multihomed >> case? > => I don't think it's the same as the on-link assumption. It's > suggested as one possible approach and is not mandated (on top of > being in the appendix), but also, it's fine to attempt address > resolution because those addresses might actually be > onlink. I.e. the node does not automatically assume that the > addresses are onlink, which was the case before. We need to somehow > address both cases: a) there is no router and some of the addresses > are in fact onlink, and b) there is no RA because there is no native > v6 connectivity and everything should go through a tunnel. Whether or not the text indicates the "on-link assumption", I still don't think the current 03 text is appropriate in this context. In fact, it's possible for a single-homed host to not receive any RA on its only interface, and "it would be fine to attempt address resolution because those addresses might actually be onlink". So, why should we then mention that in the multi-homed context? Additionally, though I'm not sure if this is related to this exact context, I suspect "attempting address resolution anyway" does not really help your case (b) above, since in this case the other end of the tunnel is most likely a router, and what the host should do is just to send the packet to the link, not trying address resolution for the destination. My primary suggestion is thus to remove "problem 1)" of Appendix A. Or, if we still want to emphasize the "complexity" of the multi-homed case, I'd rewrite it to: 1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. One possible approach for a multihomed node would be to attempt to perform address resolution on all interfaces. The same argument applies to a singlehomed node that does not receive any Router Advertisement, but the step in the multihomed case involves significant complexity. 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 May 26 13:49:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMUV-0007Og-Gp; Thu, 26 May 2005 13:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMUR-0007K3-40 for ipv6@megatron.ietf.org; Thu, 26 May 2005 13:49:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16584 for ; Thu, 26 May 2005 13:49:49 -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.33) id 1DbMn3-000789-DB for ipv6@ietf.org; Thu, 26 May 2005 14:09:07 -0400 Message-ID: <09e701c5621b$79f42690$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Thomas Narten" References: <200505261708.j4QH8dQN012721@rotala.raleigh.ibm.com> Date: Thu, 26 May 2005 10:50:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 Thomas, > Somewhat different. From an implementation perspective, one needs > access to information (e.g., whether the router's link-layer address > is in the cache) at a place in the implementation where that > information is not necessarily readily availbale. > > But, looking back over the document again, I think I've convinced > myself that this may not be a big issue after all. > OK. > However, thinking and rereading leads me to two more thoughts: > > In off-list mail: > > Jari Arkko writes: > > > > * Optimistic DAD SHOULD NOT be used to configure addresses unless the > > > probability of collision is exceedingly small. > > > > I find it very hard to implement this. More guidance would be > > needed. Did you mean "... SHOULD NOT when addresses have > > been configured manually"? > > I tend to agree. > > Actually, I wonder if what is needed is more of an applicability > statement saying what types of addresses it is appropriate to use this > procedure for, and where not. For example, can optimistic DAD be used > for the LL address? It took me some thinking to decide whether it > could or not. The answer I believe is yes, but that is not immediately > obvious, I would assert. > > But this all depends on having the link-layer address of a router in > the cache (as had been discussed already). > Well, this brings up the reason why I asked for clarification. In the DNA WG, we've been discussing how to handle the address state machine when a host moves from one wireless AP to another, potentially with both APs on the same IP link or not (the host doesn't know a priori from L2 info after movement). There's nothing currently in the DNA DT draft on the topic because we just got to discussing it when the draft was almost complete but it is on the list of issues. One way to handle this is for the host to classify the link local address as "Optimistic" then use that as the source address of a DNA RS that is multicast to All_Routers_Multicast. The RS is used to test whether the host has moved, if the RA comes back "yes, you are on the same IP link", then no additional configuration is necessary, if it comes back "no, you are on a different IP link" there's configuration information (prefixes, whether address configuration is stateful or not, etc.). In this case, there is no need for the router's link address because the host is sending the RS to an address that goes to the router anyway. And, if the host can't use "Optimistic", it would have to DAD the link address, potentially on every AP movement. In addition, if the host *has* moved to a new IP link, the DNA RA will provide the host with the router's link address, so it therefore potentially is able to autoconfigure a new unicast global address on the new link, and, putting it in "Optimistic" state, start using it for traffic by sending the traffic directly to the router while the address is being confirmed. In this case, the ability to use "Optimistic" greatly reduces handover latency, and there doesn't seem to be an issue with routing through the router because the RA provides the link address. Do you see any issues with this that I might have missed? > The second thought I have is that the security considerations section > needs some more text, something along the following lines: > > Optimistic DAD takes steps to ensure that if another node is already > using an address, the proper link-layer address in existing Neighbor > Cache Entries is not replaced with the link-layer address of the > Optimistic node. However, there are still scenarios where incorrect > entries may be created, if only temporarily. For example, if a > router (while forwarding a packet) sends out a Neighbor Solicitation > for an address, the optimistic node may respond first, and if the > router has no pre-existing link-layer address for that IP address, > it will accept the response and (incorrectly) forward any queued > packets to the optimistic node. The optimistic node may then respond > in an incorrect manner (e.g., sending a TCP RST in response to an > unknown TCP connection). Such transient conditions should be > short-lived, in most cases. > OK. > Likewise, an Optimistic node can still inject IP packets into the > Internet that will in effect be "spoofed" packets appearing to come > from the legitimate node. In some cases, those packets may lead to > errors or other operational problems, though one would expect that > upper layer protocols would generally treat such packets robustly, > in the same way they must treat old and other duplicate packets. > It is true that an Optimistic attacker can do this, but, really, can't any IPv6 node do it? An attacking node doesn't have to do DAD, it could simply come on the link and start sending packets to the Internet with whatever address it wants. It might not get anything back, of course, since any response will get sent to the legitimate owner of the address. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 26 13:57:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMcB-0000Rg-Ua; Thu, 26 May 2005 13:57:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMcA-0000Ra-Ic for ipv6@megatron.ietf.org; Thu, 26 May 2005 13:57:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16983 for ; Thu, 26 May 2005 13:57:49 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbMul-0007JP-I0 for ipv6@ietf.org; Thu, 26 May 2005 14:17:06 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4QHvXmD521898 for ; Thu, 26 May 2005 13:57:33 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4QHvX0D133076 for ; Thu, 26 May 2005 11:57:33 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4QHvWWc018498 for ; Thu, 26 May 2005 11:57:33 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4QHvWFO018486; Thu, 26 May 2005 11:57:32 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j4QHvVmI012941; Thu, 26 May 2005 13:57:31 -0400 Message-Id: <200505261757.j4QHvVmI012941@rotala.raleigh.ibm.com> To: "James Kempf" In-Reply-To: Message from kempf@docomolabs-usa.com of "Thu, 26 May 2005 10:50:51 PDT." <09e701c5621b$79f42690$016115ac@dcml.docomolabsusa.com> Date: Thu, 26 May 2005 13:57:31 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 > Well, this brings up the reason why I asked for clarification. I need to spend some time getting back up to speed with DNA, as that work is complimentary piece of this puzzle. Let me defer responding to your point until later. > > Likewise, an Optimistic node can still inject IP packets into the > > Internet that will in effect be "spoofed" packets appearing to come > > from the legitimate node. In some cases, those packets may lead to > > errors or other operational problems, though one would expect that > > upper layer protocols would generally treat such packets robustly, > > in the same way they must treat old and other duplicate packets. > > > It is true that an Optimistic attacker can do this, but, really, can't any > IPv6 node do it? An attacking node doesn't have to do DAD, it could simply > come on the link and start sending packets to the Internet with whatever > address it wants. It might not get anything back, of course, since any > response will get sent to the legitimate owner of the address. I think the key difference is that nodes running optimistic DAD may end up spoofing traffic, even though they are following the spec and are "good" nodes. I.e, there is no ill-intent, as is the case with attacking nodes. So we may end up seeing such events even in cases where there are no "attackers". 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 May 26 14:21:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMz1-00051v-9s; Thu, 26 May 2005 14:21:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbMyx-00051m-F8 for ipv6@megatron.ietf.org; Thu, 26 May 2005 14:21:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18734 for ; Thu, 26 May 2005 14:21:17 -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.33) id 1DbNHV-0007xS-ME for ipv6@ietf.org; Thu, 26 May 2005 14:40:35 -0400 Message-ID: <0a5b01c5621f$dfa073f0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Thomas Narten" References: <200505261757.j4QHvVmI012941@rotala.raleigh.ibm.com> Date: Thu, 26 May 2005 11:22:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, greg.daley@eng.monash.edu.au Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 > > > Likewise, an Optimistic node can still inject IP packets into the > > > Internet that will in effect be "spoofed" packets appearing to come > > > from the legitimate node. In some cases, those packets may lead to > > > errors or other operational problems, though one would expect that > > > upper layer protocols would generally treat such packets robustly, > > > in the same way they must treat old and other duplicate packets. > > > > > > It is true that an Optimistic attacker can do this, but, really, can't any > > IPv6 node do it? An attacking node doesn't have to do DAD, it could simply > > come on the link and start sending packets to the Internet with whatever > > address it wants. It might not get anything back, of course, since any > > response will get sent to the legitimate owner of the address. > > I think the key difference is that nodes running optimistic DAD may > end up spoofing traffic, even though they are following the spec and > are "good" nodes. I.e, there is no ill-intent, as is the case with > attacking nodes. > > So we may end up seeing such events even in cases where there are no > "attackers". > Yes, that makes sense. oDAD is really depending on the low probability of a clash. If the node is out of luck, it will of course look like spoofed traffic. Might make sense to add something like that, maybe: Optimistic DAD assumes a low probability of an address clash. If this assumption fails, an Optimistic node can still inject IP packets into the Internet ... jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 26 15:32:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbO5W-0007WD-1C; Thu, 26 May 2005 15:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbO5S-0007W8-7f for ipv6@megatron.ietf.org; Thu, 26 May 2005 15:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24622 for ; Thu, 26 May 2005 15:32:08 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbOO3-00013y-Hg for ipv6@ietf.org; Thu, 26 May 2005 15:51:27 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 May 2005 15:31:56 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2005 15:31:54 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcViGhzEyuYf0xniReqK7EX3rYybAAADt3PQ From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 26 May 2005 19:31:56.0274 (UTC) FILETIME=[93CC2D20:01C56229] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: 2461bis update 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 > My primary suggestion is thus to remove "problem 1)" of Appendix A. > Or, if we still want to emphasize the "complexity" of the multi-homed > case, I'd rewrite it to: >=20 > 1) If no Router Advertisement is received on any interfaces, a > multihomed host will have no way of knowing which=20 > interface to > send packets out on, even for on-link destinations. One > possible approach for a multihomed node would be to=20 > attempt to > perform address resolution on all interfaces. The same > argument applies to a singlehomed node that does not receive > any Router Advertisement, but the step in the multihomed case > involves significant complexity. =3D> So to be very clear, you're suggesting that if we don't remove = probem 1) then we should use=20 the above text instead of the following: If no Router Advertisement is received on any interfaces, a multihomed = host will have no way=20 of knowing which interface to send packets out on, even for on-link = destinations. One possible approach=20 for a multihomed node would be to attempt to perform address resolution = on all interfaces, a step involving=20 significant complexity. Essentially, the delta is: "The same argument applies to a singlehomed = node that does not receive any Router Advertisement" Hesham >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Thu May 26 16:07:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOe6-0002Gq-Gm; Thu, 26 May 2005 16:07:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOe3-00020R-IV for ipv6@megatron.ietf.org; Thu, 26 May 2005 16:07:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04540 for ; Thu, 26 May 2005 16:07:53 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbOwg-00049j-Q6 for ipv6@ietf.org; Thu, 26 May 2005 16:27:12 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:1515:97d3:3b2:4455]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D7FC415218; Fri, 27 May 2005 05:10:30 +0900 (JST) Date: Fri, 27 May 2005 05:08:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipv6@ietf.org Subject: Re: 2461bis update 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, 26 May 2005 15:31:54 -0400, >>>>> "Soliman, Hesham" said: >> My primary suggestion is thus to remove "problem 1)" of Appendix A. >> Or, if we still want to emphasize the "complexity" of the multi-homed >> case, I'd rewrite it to: >> >> 1) If no Router Advertisement is received on any interfaces, a >> multihomed host will have no way of knowing which >> interface to >> send packets out on, even for on-link destinations. One >> possible approach for a multihomed node would be to >> attempt to >> perform address resolution on all interfaces. The same >> argument applies to a singlehomed node that does not receive >> any Router Advertisement, but the step in the multihomed case >> involves significant complexity. > => So to be very clear, you're suggesting that if we don't remove > probem 1) then we should use the above text instead of the > following: > If no Router Advertisement is received on any interfaces, a > multihomed host will have no way of knowing which interface to send > packets out on, even for on-link destinations. One possible approach > for a multihomed node would be to attempt to perform address > resolution on all interfaces, a step involving significant > complexity. Yes. (While my primary impression is that we don't have to mention this case any more with the removal of the "on-link assumption", which makes the problem not specific to multihomed nodes) 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 May 26 16:37:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbP70-0007kE-C0; Thu, 26 May 2005 16:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbOuL-0004WP-Na; Thu, 26 May 2005 16:24:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08948; Thu, 26 May 2005 16:24:43 -0400 (EDT) Received: from rrmail4.va.rr.com ([24.30.218.96] helo=rrmailer.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbPCz-0005a5-Mw; Thu, 26 May 2005 16:44:02 -0400 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 May 2005 16:24:31 -0400 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> Thread-Topic: purpose of m/o bit Thread-Index: AcViJZrZbVZh1Iq9RIeySOTtnwFl+wABa2/A From: "da Silva, Ron" To: , , , "Thomas Narten" , "Williams, Chris" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 26 May 2005 16:37:48 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: purpose of m/o bit 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 There are nine scenarios, right? 1) RA w/auto-conf, M off, O off 2) RA w/auto-conf, M on, O off 3) RA w/auto-conf, M off, O on 4) RA w/auto-conf, M on, O on 5) RA w/o auto-conf, M off, O off 6) RA w/o auto-conf, M on, O off 7) RA w/o auto-conf, M off, O on 8) RA w/o auto-conf, M on, O on 9) No RA >From a cable deployment perspective, I would expect... 1) CM stateless auto-conf from advertised route(s) 2) CM stateless auto-conf from advertised route(s) plus DHCPv6 for additional address(es) 3) CM stateless auto-conf from advertised route(s) plus DHCPv6 for addition info 4) CM stateless auto-conf from advertised route(s) plus DHCPv6 for additional address(es) and additional info 5) same behavior as #9 below ? 6) DHCPv6 for address(es) only 7) DHCPv6 for additional info only 8) DHCPv6 for address(es) and additional info 9) CM stateless auto-conf link local address followed by DHCPv6 for additional address(es) and/or other info (same behavior as #5) This seems way to complicated though, and it would be much more deterministic for a CM to simply do #4 in all cases which would make the M/O bits useless. -ron -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 26 16: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 1DbPJB-0001nN-TW; Thu, 26 May 2005 16:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPJ6-0001mV-8n; Thu, 26 May 2005 16:50:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11133; Thu, 26 May 2005 16:50:17 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbPbk-0006Hs-12; Thu, 26 May 2005 17:09:37 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 9635E20000E4; Thu, 26 May 2005 16:50:06 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 16:50:01 -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, 26 May 2005 16:49:59 -0400 Message-ID: <936A4045C332714F975800409DE0924054128C@tayexc14.americas.cpqcorp.net> Thread-Topic: purpose of m/o bit Thread-Index: AcViJZrZbVZh1Iq9RIeySOTtnwFl+wABa2/AAAIQ1eA= From: "Bound, Jim" To: "da Silva, Ron" , , , , "Thomas Narten" , "Williams, Chris" X-OriginalArrivalTime: 26 May 2005 20:50:01.0231 (UTC) FILETIME=[7C3FE1F0:01C56234] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: purpose of m/o bit 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 Ron,=20 Thanks for doing this and this permits us to discuss it simply :--). Response on your matrix via my interpretation as implementer, no comment on your needs and appreciate you sharing that here big time, I find it very useful. Thanks. > There are nine scenarios, right? >=20 > 1) RA w/auto-conf, M off, O off Stateful is not being requested by the site or admin. No requirement to use it. > 2) RA w/auto-conf, M on, O off use stateful and other configurations available. > 3) RA w/auto-conf, M off, O on use other configurations only. =20 > 4) RA w/auto-conf, M on, O on Same as #2 is my view. > 5) RA w/o auto-conf, M off, O off > 6) RA w/o auto-conf, M on, O off > 7) RA w/o auto-conf, M off, O on > 8) RA w/o auto-conf, M on, O on My read is if auto-conf off then these bits are invalid and stateless is default. > 9) No RA Your lost and not connected have it your way :--) Use link-local :--) thanks /jim >=20 > >From a cable deployment perspective, I would expect... >=20 > 1) CM stateless auto-conf from advertised route(s) > 2) CM stateless auto-conf from advertised route(s) plus DHCPv6 for > additional address(es) > 3) CM stateless auto-conf from advertised route(s) plus DHCPv6 for > addition info > 4) CM stateless auto-conf from advertised route(s) plus DHCPv6 for > additional address(es) and additional info > 5) same behavior as #9 below ? > 6) DHCPv6 for address(es) only > 7) DHCPv6 for additional info only > 8) DHCPv6 for address(es) and additional info > 9) CM stateless auto-conf link local address followed by DHCPv6 for > additional address(es) and/or other info (same behavior as #5) >=20 > This seems way to complicated though, and it would be much more > deterministic for a CM to simply do #4 in all cases which=20 > would make the > M/O bits useless. >=20 > -ron >=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 May 26 17:34:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPze-0002Lz-6R; Thu, 26 May 2005 17:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPzb-0002LP-Dr; Thu, 26 May 2005 17:34:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14750; Thu, 26 May 2005 17:34:12 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbQIF-0007YC-J8; Thu, 26 May 2005 17:53:33 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4QLYFmJ098390 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 26 May 2005 23:34:16 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 26 May 2005 23:34:04 +0200 To: "da Silva, Ron" X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: purpose of m/o bit 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 26-mei-2005, at 22:24, da Silva, Ron wrote: > This seems way to complicated though, and it would be much more > deterministic for a CM to simply do #4 in all cases which would > make the > M/O bits useless. You know what's really deterministic? Manual configuration. There is a baby in this bath water... The problem with having different bits indicate different capabilities is that you get lots of permutations. So when a significant number of those don't make sense, having individual bits probably isn't the right choice. To me, assuming the current specs, the following would make sense: Configured for always-full-DHCPv6 on this interface? -> yes -> do full DHCPv6 | no | Timeout waiting for RAs? -> yes -> do full DHCPv6 | no | M bit set or no prefixes with AAC set? -> yes -> do full DHCPv6 | no | O bit set or always-stateless-DHCPv6 on this if? -> yes -> stateless DHCPv6 A stateless DHCPv6-only client would probably just look at the O bit and not do stateless DHCPv6 if just the M bit is set. Anyone believe that, with current knowledge and experience, implementing the above would be a bad idea? Please realize that even if something isn't useful in _your_ use case, that doesn't mean it's never useful. It's very important that people can open up their laptops, PDAs, smartphones and whathever, and it can talk to the local network _without_ _special_ _configuration_. I.e., I want to be able to bring my laptop to work where DHCPv6 is the only game in town, check my mail using a public hotspot over coffee with just stateless autoconfig and then go home and connect to my broadband connection using whatever comes out of the wall. And all this without having to change any settings. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu May 26 19:05:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRPj-0001hQ-QM; Thu, 26 May 2005 19:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbRPi-0001hI-DZ; Thu, 26 May 2005 19:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22266; Thu, 26 May 2005 19:05:15 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbRiM-0001KH-Ij; Thu, 26 May 2005 19:24:37 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 May 2005 16:05:06 -0700 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 j4QN4ic6010188; Thu, 26 May 2005 16:05:03 -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, 26 May 2005 19:05:01 -0400 Received: from 10.86.240.133 ([10.86.240.133]) 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, 26 May 2005 23:05:00 +0000 Received: from localhost.localdomain by email.cisco.com; 26 May 2005 19:05:30 -0400 From: Ralph Droms To: dhcwg@ietf.org, IETF IPv6 Mailing List In-Reply-To: References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 26 May 2005 19:05:29 -0400 Message-Id: <1117148729.7913.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 26 May 2005 23:05:01.0361 (UTC) FILETIME=[584DA210:01C56247] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Subject: Re: purpose of m/o bit 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 I'm hearing two requirements out of this thread: 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 - 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 1 is a requirement in scenarios with limited resources (e.g., wireless), where polling for DHCP is unacceptable. 2 is a requirement to avoid timeout delays or other complexity in getting ICB reply when host would prefer HCB reply. If I've got that right, we can meet the two requirements with a couple of small updates to existing specs: 1) If an RA is received with the M and/or the O bit is set, DHCP service is available over the link through which the RA was received (no differentiation between HCB and ICB DHCP) 2) If a DHCP server receives an HCB request (Solicit) but can only supply an ICB, the server can respond with the ICB reply (note that according RFC 3115, the server would respond with an "HCB-nak" [Advertise containing only an error code]) In addition to meeting the requirements, these updates are mostly (if not entirely) operationally compatible with existing clients and servers. - 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 May 26 20:49:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbT24-0002zC-IA; Thu, 26 May 2005 20:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbT20-0002yX-Eb for ipv6@megatron.ietf.org; Thu, 26 May 2005 20:48:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27446 for ; Thu, 26 May 2005 20:48:54 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbTKf-0003Qg-WB for ipv6@ietf.org; Thu, 26 May 2005 21:08:16 -0400 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOR0IOMKPC94NIBL@vaxc.its.monash.edu.au> for ipv6@ietf.org; Fri, 27 May 2005 10:48:39 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E022BAB543; Fri, 27 May 2005 10:48:38 +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 8FF144FB0C; Fri, 27 May 2005 10:48:38 +1000 (EST) Date: Fri, 27 May 2005 10:48:38 +1000 From: Greg Daley In-reply-to: <09e701c5621b$79f42690$016115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <42966E66.60901@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: <200505261708.j4QH8dQN012721@rotala.raleigh.ibm.com> <09e701c5621b$79f42690$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 2.0 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7BIT Cc: Thomas Narten , Pekka Nikander , ipv6@ietf.org Subject: DNA and oDAD (was Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed Standard) 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 James, James Kempf wrote: [cut] >> >>Actually, I wonder if what is needed is more of an applicability >>statement saying what types of addresses it is appropriate to use this >>procedure for, and where not. For example, can optimistic DAD be used >>for the LL address? It took me some thinking to decide whether it >>could or not. The answer I believe is yes, but that is not immediately >>obvious, I would assert. >> >>But this all depends on having the link-layer address of a router in >>the cache (as had been discussed already). >> > > > Well, this brings up the reason why I asked for clarification. > > In the DNA WG, we've been discussing how to handle the address state machine > when a host moves from one wireless AP to another, potentially with both APs > on the same IP link or not (the host doesn't know a priori from L2 info > after movement). There's nothing currently in the DNA DT draft on the topic > because we just got to discussing it when the draft was almost complete but > it is on the list of issues. [dna context cut] > > Do you see any issues with this that I might have missed? > DNA has been considering DAD issues informally for a long time, even though there's no text in the current proposal (oDAD was once a potential charter item for the group). I think it is now believed necessary to use Optimistic DAD with a link-local address while testing whether reconfiguration is needed. The main issues with using Optimistic DAD for DNA seem to be as follows: 1 There's a requirement to include the SLLAO into the RA for DNA routers, otherwise the DNA host incurs full DAD delay before resolving the router address. It may be able to detect link change though... 2 Non SEND addresses can be stolen by fake DAD defences upon the host entering DNA (for example cell change within a link). This is not a new attack, but an extension of its applicability. 3 RS's cannot contain an SLLAO in Optimistic DAD. This either causes a multicast response, or an additional address resolution by the router toward the host. The first issue cannot be controlled by DNA hosts (since they may visit networks where compliant 2461 routers don't include the option. It may be worth describing in one of the documents (DNA for hosts ??). Including SLLAO in RAs should be mentioned in DNA for routers (I'll check that it is). The second issue needs a few words in the DNA for hosts document, and should probably mention how SEND can be used to defend against it. (I'll check that this is there). The third issue remains problematic for DNA hosts in that in some circumstances there will be 2461 routers which won't unicast respond to an RS without SLLAO. This will induce (further) delay. What would really help things along would be a Tentative Source Link-Layer Address Option, which could be used to create a STALE NCE on the router, iff there's no existing NCE with a different MAC address. The existing DNA DT proposal (not a WG document) in DNA requires use of such options, but refers to a separate draft (I'm one of the TSLLAO authors). If the DNA WG needs the option, perhaps it would be better to look at that option in IPv6 WG though, because of its DAD expertise. 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 May 27 08:46:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeE4-0005yi-EX; Fri, 27 May 2005 08:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeDy-0005w3-QC; Fri, 27 May 2005 08:46:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06945; Fri, 27 May 2005 08:46:01 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbeWl-0001tN-4J; Fri, 27 May 2005 09:05:28 -0400 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 13:45:50 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 May 2005 13:45:50 +0100 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 13:41:34 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A700F24D9E2@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: purpose of m/o bit Thread-Index: AcViR4lYtZM4t8WYQFKqxQUEvGp5oAAcSjlQ To: , , X-OriginalArrivalTime: 27 May 2005 12:45:50.0334 (UTC) FILETIME=[02FA89E0:01C562BA] X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: purpose of m/o bit 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 Ralph Droms wrote: > Seems to me I'm hearing two requirements out of this thread: >=20 > 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 >=20 > 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 >=20 > 1 is a requirement in scenarios with limited resources (e.g., > wireless), where polling for DHCP is unacceptable. 2 is a > requirement to avoid timeout delays or other complexity in getting > ICB reply when=20 > host would > prefer HCB reply. >=20 > If I've got that right, we can meet the two requirements with a couple > of small updates to existing specs: >=20 > 1) If an RA is received with the M and/or the O bit is set, DHCP > service is available over the link through which the RA > was received > (no differentiation between HCB and ICB DHCP) >=20 > 2) If a DHCP server receives an HCB request (Solicit) but can only > supply an ICB, the server can respond with the ICB reply (note that > according RFC 3115, the server would respond with an "HCB-nak" > [Advertise containing only an error code]) >=20 > In addition to meeting the requirements, these updates are mostly (if > not entirely) operationally compatible with existing clients and > servers.=20 I completely agree with this analysis and support proceeding on this basis. But it does beg the question, why do we need two bits to signal a binary condition? -- Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 08:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeOe-0007zX-Dv; Fri, 27 May 2005 08:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeOa-0007xX-Bv; Fri, 27 May 2005 08:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07615; Fri, 27 May 2005 08:56:59 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbehO-00027o-0D; Fri, 27 May 2005 09:16:26 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 08:56:51 -0400 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 j4RCuUlM002666; Fri, 27 May 2005 08:56:48 -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); Fri, 27 May 2005 08:56:28 -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: Fri, 27 May 2005 08:56:27 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338C91@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViR4lYtZM4t8WYQFKqxQUEvGp5oAAcSjlQAACA9iA= From: "Bernie Volz \(volz\)" To: , "Ralph Droms \(rdroms\)" , , X-OriginalArrivalTime: 27 May 2005 12:56:28.0809 (UTC) FILETIME=[7F8A1790:01C562BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: [dhcwg] RE: purpose of m/o bit 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 We don't but it avoids issues with backwards compatibility (though I don't believe that is a big issue yet). I think if we come to agreement on having no distinction between the bits, we should deprecate one of the bits (O-bit?); though for backwards compatibility, we can't remove/reassign it until many years from now (if ever). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of matthew.ford@bt.com > Sent: Friday, May 27, 2005 8:42 AM > To: Ralph Droms (rdroms); dhcwg@ietf.org; ipv6@ietf.org > Subject: [dhcwg] RE: purpose of m/o bit >=20 > Ralph Droms wrote: >=20 > > Seems to me I'm hearing two requirements out of this thread: > >=20 > > 1) Ability to indicate to a host "DHCP is not available on=20 > this link", > > with the expectation that the host won't send any DHCP messages > >=20 > > 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 > >=20 > > 1 is a requirement in scenarios with limited resources (e.g., > > wireless), where polling for DHCP is unacceptable. 2 is a > > requirement to avoid timeout delays or other complexity in getting > > ICB reply when=20 > > host would > > prefer HCB reply. > >=20 > > If I've got that right, we can meet the two requirements=20 > with a couple > > of small updates to existing specs: > >=20 > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > service is available over the link through which the RA > > was received > > (no differentiation between HCB and ICB DHCP) > >=20 > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > supply an ICB, the server can respond with the ICB reply=20 > (note that > > according RFC 3115, the server would respond with an "HCB-nak" > > [Advertise containing only an error code]) > >=20 > > In addition to meeting the requirements, these updates are=20 > mostly (if > > not entirely) operationally compatible with existing clients and > > servers.=20 >=20 > I completely agree with this analysis and support proceeding on this > basis. But it does beg the question, why do we need two bits=20 > to signal a > binary condition? >=20 > -- Mat >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 08:59:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeQY-0008J0-1K; Fri, 27 May 2005 08:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeQS-0008Ie-4m; Fri, 27 May 2005 08:58:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07695; Fri, 27 May 2005 08:58:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbejE-0002Aw-Nq; Fri, 27 May 2005 09:18:22 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 08:58:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RCwgl6003220; Fri, 27 May 2005 08:58:42 -0400 (EDT) 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); Fri, 27 May 2005 08:58:40 -0400 Received: from 10.86.240.133 ([10.86.240.133]) 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 ; Fri, 27 May 2005 12:58:39 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 08:59:09 -0400 From: Ralph Droms To: matthew.ford@bt.com In-Reply-To: <0AAF93247C75E3408638B965DEE11A700F24D9E2@i2km41-ukdy.domain1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A700F24D9E2@i2km41-ukdy.domain1.systemhost.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 08:59:08 -0400 Message-Id: <1117198748.7913.79.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 12:58:40.0275 (UTC) FILETIME=[CDE63630:01C562BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: purpose of m/o bit 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 Mat - thanks for your review and input. I specified the two bits only for backward compatibility with existing implementations. I imagine we could design a specification that retains one bit and deprecates the other, with rules about the appearance of the depre backward compatibility. At least, this spec would need a note explaining why there are two bits in the spec and recommending that new implementations use, for example, just the M bit. - Ralph On Fri, 2005-05-27 at 13:41 +0100, matthew.ford@bt.com wrote: > Ralph Droms wrote: > > > Seems to me I'm hearing two requirements out of this thread: > > > > 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 > > - 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 > > > > 1 is a requirement in scenarios with limited resources (e.g., > > wireless), where polling for DHCP is unacceptable. 2 is a > > requirement to avoid timeout delays or other complexity in getting > > ICB reply when > > host would > > prefer HCB reply. > > > > If I've got that right, we can meet the two requirements with a couple > > of small updates to existing specs: > > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > service is available over the link through which the RA > > was received > > (no differentiation between HCB and ICB DHCP) > > > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > supply an ICB, the server can respond with the ICB reply (note that > > according RFC 3115, the server would respond with an "HCB-nak" > > [Advertise containing only an error code]) > > > > In addition to meeting the requirements, these updates are mostly (if > > not entirely) operationally compatible with existing clients and > > servers. > > I completely agree with this analysis and support proceeding on this > basis. But it does beg the question, why do we need two bits to signal a > binary condition? > > -- Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 09:07:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeYt-0001yN-0r; Fri, 27 May 2005 09:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeYr-0001vg-EJ; Fri, 27 May 2005 09:07:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08690; Fri, 27 May 2005 09:07:36 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbere-0002TN-6R; Fri, 27 May 2005 09:27:03 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RD7cmJ009903 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 15:07:39 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338C91@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338C91@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66D05231-EE27-4AF9-B197-D4E50AA35C86@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 27 May 2005 15:07:20 +0200 To: Bernie Volz ((volz)) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit 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 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote: > I think if we come to agreement on having no distinction between the > bits, we should deprecate one of the bits (O-bit?); though for > backwards > compatibility, we can't remove/reassign it until many years from > now (if > ever). I think having M = 0, O = 1 would be useful as an indication that clients should use the simplified stateless DHCPv6 rather than the full DHCPv6. And I would object to any deprecation on the basis that there isn't enough operational experience to be able to make a good decision. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 09:18:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbejr-0005ez-SU; Fri, 27 May 2005 09:18:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbejp-0005eZ-Dk; Fri, 27 May 2005 09:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09636; Fri, 27 May 2005 09:18:56 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbf2c-0002mS-8A; Fri, 27 May 2005 09:38:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 09:18:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDI95I014281; Fri, 27 May 2005 09:18:44 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:18:15 -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: Fri, 27 May 2005 09:18:14 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVivR4fj/53Kf3FRE61JK+gHvwwhgAAGKFA From: "Bernie Volz \(volz\)" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 13:18:15.0220 (UTC) FILETIME=[8A389740:01C562BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 Why? If we update the DHCPv6 protocol to allow "other configuration" options to be returned in an Advertise for a Solicit, Information-Request/Reply and Solicit/Advertise are then essentially the same in a stateless DHCPv6 environment (though the Solicit does require a client identifier and likely may require a IA_* option). Note that this will require changes to 3315 and 3736 - since stateless servers will need to respond to Solicits with Advertises. Clients that can do full 3315, would. And, if no stateful DHCPv6 server is available but a stateless is, it will get "other configuration parameters". Clients that only do 3736 would do that and get "other configuration parameters". I think if we have two bits, we'll just be back to some of the edge conditions (what if M is set, but O isn't, etc). These changes would potentially cause some issues with any deployments today because the clients and servers do not support this "new" behavior, but it that's why it is critical we work this out ASAP. However, those clients, if they use the M & O bits, could continue to do what they do today -- since both bits are available. It is just new clients with old servers that may have issues. - Bernie > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Friday, May 27, 2005 9:07 AM > To: Bernie Volz (volz) > Cc: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote: >=20 > > I think if we come to agreement on having no distinction between the > > bits, we should deprecate one of the bits (O-bit?); though for =20 > > backwards > > compatibility, we can't remove/reassign it until many years from =20 > > now (if > > ever). >=20 > I think having M =3D 0, O =3D 1 would be useful as an indication that = > clients should use the simplified stateless DHCPv6 rather than the =20 > full DHCPv6. >=20 > And I would object to any deprecation on the basis that there isn't =20 > enough operational experience to be able to make a good decision. >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 09:44:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbf8e-0002sk-IA; Fri, 27 May 2005 09:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbf8c-0002sX-Lj; Fri, 27 May 2005 09:44:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11312; Fri, 27 May 2005 09:44: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.33) id 1DbfRP-0003LN-JR; Fri, 27 May 2005 10:04:01 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 May 2005 06:44:22 -0700 X-IronPort-AV: i="3.93,143,1115017200"; d="scan'208"; a="270483785:sNHT31067240" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDhZmQ019164; Fri, 27 May 2005 06:44:16 -0700 (PDT) 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); Fri, 27 May 2005 09:44:13 -0400 Received: from 10.86.240.133 ([10.86.240.133]) 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 ; Fri, 27 May 2005 13:44:13 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 09:44:42 -0400 From: Ralph Droms To: "da Silva, Ron" In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 09:44:42 -0400 Message-Id: <1117201482.7913.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 13:44:13.0815 (UTC) FILETIME=[2B375070:01C562C2] X-Spam-Score: 2.2 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , IETF IPv6 Mailing List Subject: Re: [dhcwg] Re: purpose of m/o bit 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 Ron - Use of AAC on specific prefixes advertised in RAs, as controlled by the A bit in a prefix information option, is independent of the use of DHCP ... so you're right, if there are prefixes in an RA with the A bit set, and the M and/or O bits are set in that RA, the host would configure both AAC addresses and DHCP-assigned addresses. I didn't include anything about AAC in the analysis I posted because I think they are completely independent... - Ralph On Fri, 2005-05-27 at 09:30 -0400, da Silva, Ron wrote: > > To me, assuming the current specs, the following would make sense: > > One of the permutations missing in your algorithm is if a device is > configured for always-full-DHCPv6 on an interface AND it receives RA > with AAC set...I presume in that case the device would get multiple > addresses, right? > > -ron > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 09:48:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfCf-0003L2-Vm; Fri, 27 May 2005 09:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbevN-0008QD-QJ; Fri, 27 May 2005 09:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10512; Fri, 27 May 2005 09:30:50 -0400 (EDT) Received: from rrmail4.va.rr.com ([24.30.218.96] helo=rrmailer.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfE8-00035C-QY; Fri, 27 May 2005 09:50:17 -0400 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2005 09:30:37 -0400 Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> Thread-Topic: purpose of m/o bit Thread-Index: AcViOrBwWse2g8nwRhSHR30WE/CGagAhP9+Q From: "da Silva, Ron" To: "Iljitsch van Beijnum" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 27 May 2005 09:48:43 -0400 Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: purpose of m/o bit 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 > To me, assuming the current specs, the following would make sense: One of the permutations missing in your algorithm is if a device is configured for always-full-DHCPv6 on an interface AND it receives RA with AAC set...I presume in that case the device would get multiple addresses, right? -ron -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 09:50:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfEN-0003b1-9S; Fri, 27 May 2005 09:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfEL-0003at-9B; Fri, 27 May 2005 09:50:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11865; Fri, 27 May 2005 09:50:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfX8-0003Uu-8V; Fri, 27 May 2005 10:09:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 09:49:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDnF50023440; Fri, 27 May 2005 09:49:25 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:49:17 -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: Fri, 27 May 2005 09:49:16 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338CB9@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcViOrBwWse2g8nwRhSHR30WE/CGagAhP9+QAACRCZA= From: "Bernie Volz \(volz\)" To: "da Silva, Ron" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 13:49:17.0771 (UTC) FILETIME=[E06351B0:01C562C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit 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 Depends on what the DHCPv6 server is configured to do. AAC and DHCPv6 can assign addresses on the same prefix, but I would suspect that in most deployments there is little reason to do that. Instead, DHCPv6 would likely assign addresses on prefixes that are not AAC. More likley is that you have a unique local prefix that you allow AAC for. But, for a global unicast address you need to go to DHCPv6. The DHCPv6 server would *NOT* likely assign another unique local address for that client. Just because a prefix is advertised as AAC or not, does not imply ANYTHING about what DHCPv6 would do for that prefix. Though in practice there is little reason to use both AAC and DHCPv6 on that single prefix. Though there may be good reason to do AAC on some prefixes and DHCPv6 on others if multiple prefixes are active. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of da Silva, Ron > Sent: Friday, May 27, 2005 9:31 AM > To: Iljitsch van Beijnum > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit >=20 > > To me, assuming the current specs, the following would make sense: >=20 > One of the permutations missing in your algorithm is if a device is > configured for always-full-DHCPv6 on an interface AND it receives RA > with AAC set...I presume in that case the device would get multiple > addresses, right? >=20 > -ron >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 09:52:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfG5-0003rf-Jw; Fri, 27 May 2005 09:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbfG2-0003rU-Pb; Fri, 27 May 2005 09:52:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12016; Fri, 27 May 2005 09:52:13 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfYq-0003ZE-Ss; Fri, 27 May 2005 10:11:41 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 09:52:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RDpmlI020958; Fri, 27 May 2005 09:52:01 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 09:52:01 -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: Fri, 27 May 2005 09:52:00 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338CBE@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcViwsj0jKoQCvbuQneFjb54abIRlQAAFfIg From: "Bernie Volz \(volz\)" To: "Ralph Droms \(rdroms\)" , "da Silva, Ron" X-OriginalArrivalTime: 27 May 2005 13:52:01.0082 (UTC) FILETIME=[41BA99A0:01C562C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit 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 > if there are prefixes in an RA with the A > bit set, and the M and/or O bits are set in that RA, the host would > configure both AAC addresses and DHCP-assigned addresses. That assumes that the DHCPv6 will provide addresses on that prefix. In most cases, I would suspect that is not the case. However, the DHCPv6 server would assign addresses on other prefixes. =20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms (rdroms) > Sent: Friday, May 27, 2005 9:45 AM > To: da Silva, Ron > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; IETF IPv6 Mailing List > Subject: Re: [dhcwg] Re: purpose of m/o bit >=20 > Ron - Use of AAC on specific prefixes advertised in RAs, as controlled > by the A bit in a prefix information option, is independent of the use > of DHCP ... so you're right, if there are prefixes in an RA with the A > bit set, and the M and/or O bits are set in that RA, the host would > configure both AAC addresses and DHCP-assigned addresses. >=20 > I didn't include anything about AAC in the analysis I posted because I > think they are completely independent... >=20 > - Ralph >=20 > On Fri, 2005-05-27 at 09:30 -0400, da Silva, Ron wrote: > > > To me, assuming the current specs, the following would make sense: > >=20 > > One of the permutations missing in your algorithm is if a device is > > configured for always-full-DHCPv6 on an interface AND it receives RA > > with AAC set...I presume in that case the device would get multiple > > addresses, right? > >=20 > > -ron > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 10:42:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbg2D-00081b-Jz; Fri, 27 May 2005 10:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbg2C-00081T-03; Fri, 27 May 2005 10:42:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17629; Fri, 27 May 2005 10:41:58 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbgKz-0004mK-BT; Fri, 27 May 2005 11:01:26 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 10:41:50 -0400 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 j4REfT5C011025; Fri, 27 May 2005 10:41:47 -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); Fri, 27 May 2005 10:41:46 -0400 Received: from 161.44.65.252 ([161.44.65.252]) 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 ; Fri, 27 May 2005 14:41:46 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 10:42:15 -0400 From: Ralph Droms To: "Bernie Volz (volz)" In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CBE@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338CBE@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 10:42:14 -0400 Message-Id: <1117204934.9663.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 14:41:46.0342 (UTC) FILETIME=[35152060:01C562CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , IETF IPv6 Mailing List , "da Silva, Ron" Subject: RE: [dhcwg] Re: purpose of m/o bit 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 didn't mean to imply that the AAC and DHCP addresses would come from the same prefix - there's nothing that precludes such assignment; I can't think of a reason why it would be done in practice. I simply stated that the host would configure a collection of AAC addresses and DHCP-assigned addresses from the collection of prefixes available on the link. - Ralph On Fri, 2005-05-27 at 09:52 -0400, Bernie Volz (volz) wrote: > > if there are prefixes in an RA with the A > > bit set, and the M and/or O bits are set in that RA, the host would > > configure both AAC addresses and DHCP-assigned addresses. > > That assumes that the DHCPv6 will provide addresses on that prefix. In > most cases, I would suspect that is not the case. However, the DHCPv6 > server would assign addresses on other prefixes. > > > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Ralph Droms (rdroms) > > Sent: Friday, May 27, 2005 9:45 AM > > To: da Silva, Ron > > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; IETF IPv6 Mailing List > > Subject: Re: [dhcwg] Re: purpose of m/o bit > > > > Ron - Use of AAC on specific prefixes advertised in RAs, as controlled > > by the A bit in a prefix information option, is independent of the use > > of DHCP ... so you're right, if there are prefixes in an RA with the A > > bit set, and the M and/or O bits are set in that RA, the host would > > configure both AAC addresses and DHCP-assigned addresses. > > > > I didn't include anything about AAC in the analysis I posted because I > > think they are completely independent... > > > > - Ralph > > > > On Fri, 2005-05-27 at 09:30 -0400, da Silva, Ron wrote: > > > > To me, assuming the current specs, the following would make sense: > > > > > > One of the permutations missing in your algorithm is if a device is > > > configured for always-full-DHCPv6 on an interface AND it receives RA > > > with AAC set...I presume in that case the device would get multiple > > > addresses, right? > > > > > > -ron > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:02:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhIA-0007Kg-2t; Fri, 27 May 2005 12:02:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhI8-0007KS-56; Fri, 27 May 2005 12:02:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22609; Fri, 27 May 2005 12:02:29 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbhaw-0006VK-6X; Fri, 27 May 2005 12:21:59 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RG2WmJ012503 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 18:02:33 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6448C0ED-58E1-4749-9B9E-E5BE06D816E4@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 27 May 2005 18:02:22 +0200 To: Bernie Volz ((volz)) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit 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 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote: > Why? Well, why not? I'm not too familiar with the internals of DHCPv6, but I can imagine that it would be moderately useful if a client knows in advance whether it's going to do full DHCP and may receive stateful information, or it's only going to obtain some stateless information. I'm not sure if we would be designing this today that we'd include an O bit, but it's here, and using it in this way comes reasonably close to its original meaning AND may provide some benefits, so why go through the trouble of doing something radical now? > If we update the DHCPv6 protocol to allow "other configuration" > options > to be returned in an Advertise for a Solicit, Information-Request/ > Reply > and Solicit/Advertise are then essentially the same in a stateless > DHCPv6 environment (though the Solicit does require a client > identifier > and likely may require a IA_* option). So we need to do more protocol work in order to send larger packets so we can get rid of a bit that doesn't bother anyone? Hm... > I think if we have two bits, we'll just be back to some of the edge > conditions (what if M is set, but O isn't, etc). I think I addressed that in my message yesterday, for the most part. If we ignore all other input and just look at the bits, then: M O stateful clients stateless clients 0 0 do nothing do nothing 1 0 send Solicit do nothing 0 1 send Information-Request send Information-Request 1 1 send Solicit send Information-Request The compelling advantage here would be that it's possible to run a server that only understands stateless DHCPv6. (I'm assuming that you need a server that implements full DHCPv6 to answer Solicits even if it otherwise only serves up stateless information.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:13:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhSF-0000Bh-VP; Fri, 27 May 2005 12:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhSE-0000B6-4E; Fri, 27 May 2005 12:12:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23270; Fri, 27 May 2005 12:12:55 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbhl3-0006k2-Fd; Fri, 27 May 2005 12:32:25 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RGD3mJ012663 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 18:13:03 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F122@RRMAILER.rr.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BEBBF0B-D240-4347-819F-6F2F5F7EF076@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 27 May 2005 18:12:53 +0200 To: "da Silva, Ron" X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: purpose of m/o bit 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 27-mei-2005, at 15:30, da Silva, Ron wrote: > One of the permutations missing in your algorithm is if a device is > configured for always-full-DHCPv6 on an interface AND it receives RA > with AAC set...I presume in that case the device would get multiple > addresses, right? Like Ralph, I didn't include those because stateless autoconfiguration happens independent from DHCPv6. But now that you ask... Over in shim6/multi6 we're thinking about multihoming mechanisms where security is derived from "hash-based addresses": the hash over certain information is used as an interface identifier. It would be nice to be able to implement all of this in middleboxes rather than / in addition to hosts, but then we need to have a way to assign a specific address to a host. In order to provide "legacy" IPv6 connectivity we need to do stateless address autoconfig, but it would be nice if we could make the hosts in question ignore those addresses and just use the hash-based one obtained from a DHCP server. (Note that the above goes several steps further than the official wg consensus, just thinking ahead.) I guess there are two ways to do this: an ND/RA option that tells a host how to use stateless autoconfig and/or DHCP derived addresses, or a DHCPv6 option that does the same. I.e., such an option could tell the host "don't use stateless autoconfig". Thinking about this stuff, I wondered: - how does the DHCP server know which prefixes are on-link for the host? - what happens when the DHCP server assigns an address that the router doesn't recognize as on-link? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhVb-0001pG-Uy; Fri, 27 May 2005 12:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhVa-0001n5-56; Fri, 27 May 2005 12:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23962; Fri, 27 May 2005 12:16:23 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbhoO-0006vX-Ao; Fri, 27 May 2005 12:35:53 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 12:16:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RGG9l8009987; Fri, 27 May 2005 12:16:11 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:16:06 -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: Fri, 27 May 2005 12:16:05 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338D2D@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi1Z44jKqEXt8rRzOjUX7fwuzm+gAADvvQ From: "Bernie Volz \(volz\)" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 16:16:06.0339 (UTC) FILETIME=[62B42130:01C562D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, dhcwg@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 > 1 1 send Solicit send Information-Request But what happens if the stateful server is down and stateless is running? Though I would never recommend that a link have both of these types of servers. We could easily resolve this by adjusting the DHCPv6 protocol as proposed (ie, stateful and stateless servers can respond to Solicit with Advertise with just other configuration parameters). Then, if people feel that there is value in having the two bits, all will work. Of course, there is the issue that the stateful server is down and later returns, but I would argue that it would be a BAD idea to run BOTH a stateful and stateless server on a single link -- run ONE type or the OTHER; not both! We really want to communicate three states in terms of the DHCPv6 service available on the link: No DHCPv6, Stateful DHCPv6, and Stateless DHCPv6 -- not 4. Note that this says nothing about what a client supports (if the client can only do stateless, that's all it can do!). Clients would run DHCPv6 unless the "No DHCPv6" is set. So, perhaps we should deprecate M=3D1 *AND* O=3D1. Clients should always = run DHCPv6 if EITHER M =3D 1 OR O =3D 1. If M=3D1, run stateful (if = supported, stateless otherwise). If O=3D1, run stateless (if supported). In any case, I would still fix the DHCPv6 protocol to allow Advertises to return other configuration parameters when no addresses are available AND to require stateless DHCPv6 servers to support Solicit (with Advertise with just other configuration parameters). I still believe deprecating the 2nd bit (O) is better. - Bernie > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Friday, May 27, 2005 12:02 PM > To: Bernie Volz (volz) > Cc: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote: >=20 > > Why? >=20 > Well, why not? >=20 > I'm not too familiar with the internals of DHCPv6, but I can imagine =20 > that it would be moderately useful if a client knows in advance =20 > whether it's going to do full DHCP and may receive stateful =20 > information, or it's only going to obtain some stateless information. >=20 > I'm not sure if we would be designing this today that we'd=20 > include an =20 > O bit, but it's here, and using it in this way comes=20 > reasonably close =20 > to its original meaning AND may provide some benefits, so why go =20 > through the trouble of doing something radical now? >=20 > > If we update the DHCPv6 protocol to allow "other configuration" =20 > > options > > to be returned in an Advertise for a Solicit, Information-Request/=20 > > Reply > > and Solicit/Advertise are then essentially the same in a stateless > > DHCPv6 environment (though the Solicit does require a client =20 > > identifier > > and likely may require a IA_* option). >=20 > So we need to do more protocol work in order to send larger packets =20 > so we can get rid of a bit that doesn't bother anyone? Hm... >=20 > > I think if we have two bits, we'll just be back to some of the edge > > conditions (what if M is set, but O isn't, etc). >=20 > I think I addressed that in my message yesterday, for the most part. =20 > If we ignore all other input and just look at the bits, then: >=20 > M O stateful clients stateless clients > 0 0 do nothing do nothing > 1 0 send Solicit do nothing > 0 1 send Information-Request send Information-Request > 1 1 send Solicit send Information-Request >=20 > The compelling advantage here would be that it's possible to run a =20 > server that only understands stateless DHCPv6. (I'm assuming=20 > that you =20 > need a server that implements full DHCPv6 to answer Solicits even if =20 > it otherwise only serves up stateless information.) >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:31:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhkC-0006YH-03; Fri, 27 May 2005 12:31:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhkA-0006Xj-JW; Fri, 27 May 2005 12:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24923; Fri, 27 May 2005 12:31:28 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi2x-0007K8-Ji; Fri, 27 May 2005 12:50:57 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id D0EA6189; Fri, 27 May 2005 12:28:51 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:30:38 -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: Fri, 27 May 2005 12:30:33 -0400 Message-ID: <936A4045C332714F975800409DE092405414F6@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViR4lYtZM4t8WYQFKqxQUEvGp5oAAcSjlQAACA9iAAB6alUA== From: "Bound, Jim" To: "Bernie Volz (volz)" , , "Ralph Droms (rdroms)" , , X-OriginalArrivalTime: 27 May 2005 16:30:38.0924 (UTC) FILETIME=[6ACE08C0:01C562D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: [dhcwg] RE: purpose of m/o bit 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 o bit was to state use dhcpv6 but not for addresses. it is not binary but ternary. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Bernie Volz (volz) > Sent: Friday, May 27, 2005 8:56 AM > To: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 > We don't but it avoids issues with backwards compatibility (though I > don't believe that is a big issue yet). >=20 > I think if we come to agreement on having no distinction between the > bits, we should deprecate one of the bits (O-bit?); though=20 > for backwards > compatibility, we can't remove/reassign it until many years=20 > from now (if > ever). >=20 > - Bernie >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > > On Behalf Of matthew.ford@bt.com > > Sent: Friday, May 27, 2005 8:42 AM > > To: Ralph Droms (rdroms); dhcwg@ietf.org; ipv6@ietf.org > > Subject: [dhcwg] RE: purpose of m/o bit > >=20 > > Ralph Droms wrote: > >=20 > > > Seems to me I'm hearing two requirements out of this thread: > > >=20 > > > 1) Ability to indicate to a host "DHCP is not available on=20 > > this link", > > > with the expectation that the host won't send any DHCP messages > > >=20 > > > 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 > > >=20 > > > 1 is a requirement in scenarios with limited resources (e.g., > > > wireless), where polling for DHCP is unacceptable. 2 is a > > > requirement to avoid timeout delays or other complexity in getting > > > ICB reply when=20 > > > host would > > > prefer HCB reply. > > >=20 > > > If I've got that right, we can meet the two requirements=20 > > with a couple > > > of small updates to existing specs: > > >=20 > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > > service is available over the link through which the RA > > > was received > > > (no differentiation between HCB and ICB DHCP) > > >=20 > > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > > supply an ICB, the server can respond with the ICB reply=20 > > (note that > > > according RFC 3115, the server would respond with an "HCB-nak" > > > [Advertise containing only an error code]) > > >=20 > > > In addition to meeting the requirements, these updates are=20 > > mostly (if > > > not entirely) operationally compatible with existing clients and > > > servers.=20 > >=20 > > I completely agree with this analysis and support proceeding on this > > basis. But it does beg the question, why do we need two bits=20 > > to signal a > > binary condition? > >=20 > > -- Mat > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=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 Fri May 27 12:32:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhl6-0006b7-NX; Fri, 27 May 2005 12:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhl5-0006aa-52; Fri, 27 May 2005 12:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24974; Fri, 27 May 2005 12:32:24 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi3u-0007Kk-Ba; Fri, 27 May 2005 12:51:55 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id EC6341A5; Fri, 27 May 2005 12:29:55 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:32:14 -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: Fri, 27 May 2005 12:32:12 -0400 Message-ID: <936A4045C332714F975800409DE092405414F8@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViu/KLWFDdMW0aQBKaNLO1HM9CWgAHYKxA From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 27 May 2005 16:32:14.0076 (UTC) FILETIME=[A38513C0:01C562D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: [dhcwg] RE: purpose of m/o bit 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 m =3D=3D use dhc for addresses, o =3D=3D use dhc for just configuration = bow do you do this with one bit? neither m or o not set says don't use dhc. thus my reason for ternary. thx /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Friday, May 27, 2005 8:59 AM > To: matthew.ford@bt.com > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: [dhcwg] RE: purpose of m/o bit >=20 > Mat - thanks for your review and input. I specified the two bits only > for backward compatibility with existing implementations. >=20 > I imagine we could design a specification that retains one bit and > deprecates the other, with rules about the appearance of the depre > backward compatibility. At least, this spec would need a note > explaining why there are two bits in the spec and=20 > recommending that new > implementations use, for example, just the M bit. >=20 > - Ralph >=20 > On Fri, 2005-05-27 at 13:41 +0100, matthew.ford@bt.com wrote: > > Ralph Droms wrote: > >=20 > > > Seems to me I'm hearing two requirements out of this thread: > > >=20 > > > 1) Ability to indicate to a host "DHCP is not available=20 > on this link", > > > with the expectation that the host won't send any DHCP messages > > >=20 > > > 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 > > >=20 > > > 1 is a requirement in scenarios with limited resources (e.g., > > > wireless), where polling for DHCP is unacceptable. 2 is a > > > requirement to avoid timeout delays or other complexity in getting > > > ICB reply when=20 > > > host would > > > prefer HCB reply. > > >=20 > > > If I've got that right, we can meet the two requirements=20 > with a couple > > > of small updates to existing specs: > > >=20 > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > > service is available over the link through which the RA > > > was received > > > (no differentiation between HCB and ICB DHCP) > > >=20 > > > 2) If a DHCP server receives an HCB request (Solicit) but can only > > > supply an ICB, the server can respond with the ICB=20 > reply (note that > > > according RFC 3115, the server would respond with an "HCB-nak" > > > [Advertise containing only an error code]) > > >=20 > > > In addition to meeting the requirements, these updates=20 > are mostly (if > > > not entirely) operationally compatible with existing clients and > > > servers.=20 > >=20 > > I completely agree with this analysis and support proceeding on this > > basis. But it does beg the question, why do we need two=20 > bits to signal a > > binary condition? > >=20 > > -- Mat >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:34:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhn7-0006ir-1g; Fri, 27 May 2005 12:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhn5-0006iK-KE; Fri, 27 May 2005 12:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25126; Fri, 27 May 2005 12:34:29 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi5t-0007ON-TM; Fri, 27 May 2005 12:53:59 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id B58C615B; Fri, 27 May 2005 12:31:59 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:34:15 -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: Fri, 27 May 2005 12:34:13 -0400 Message-ID: <936A4045C332714F975800409DE092405414FC@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVivR4fj/53Kf3FRE61JK+gHvwwhgAAGKFAAAcQD2A= From: "Bound, Jim" To: "Bernie Volz (volz)" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2005 16:34:15.0462 (UTC) FILETIME=[EBDF1C60:01C562D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 because thinking was router should be able to tell client use for addresses and not configuration or use just for configuration, or don't even use dhc. no comment on that I agree or disagree this is just what the purpose was. agree or not agree can only happen once people get why what is there is there. /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Bernie Volz (volz) > Sent: Friday, May 27, 2005 9:18 AM > To: Iljitsch van Beijnum > Cc: ipv6@ietf.org; dhcwg@ietf.org; Ralph Droms (rdroms) > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 > Why? >=20 > If we update the DHCPv6 protocol to allow "other=20 > configuration" options > to be returned in an Advertise for a Solicit,=20 > Information-Request/Reply > and Solicit/Advertise are then essentially the same in a stateless > DHCPv6 environment (though the Solicit does require a client=20 > identifier > and likely may require a IA_* option). >=20 > Note that this will require changes to 3315 and 3736 - since stateless > servers will need to respond to Solicits with Advertises. >=20 > Clients that can do full 3315, would. And, if no stateful=20 > DHCPv6 server > is available but a stateless is, it will get "other configuration > parameters". >=20 > Clients that only do 3736 would do that and get "other configuration > parameters". >=20 > I think if we have two bits, we'll just be back to some of the edge > conditions (what if M is set, but O isn't, etc). >=20 > These changes would potentially cause some issues with any deployments > today because the clients and servers do not support this "new" > behavior, but it that's why it is critical we work this out ASAP. > However, those clients, if they use the M & O bits, could=20 > continue to do > what they do today -- since both bits are available. It is just new > clients with old servers that may have issues. >=20 > - Bernie >=20 > > -----Original Message----- > > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > > Sent: Friday, May 27, 2005 9:07 AM > > To: Bernie Volz (volz) > > Cc: matthew.ford@bt.com; Ralph Droms (rdroms);=20 > > dhcwg@ietf.org; ipv6@ietf.org > > Subject: Re: [dhcwg] RE: purpose of m/o bit > >=20 > > On 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote: > >=20 > > > I think if we come to agreement on having no distinction=20 > between the > > > bits, we should deprecate one of the bits (O-bit?); though for =20 > > > backwards > > > compatibility, we can't remove/reassign it until many years from =20 > > > now (if > > > ever). > >=20 > > I think having M =3D 0, O =3D 1 would be useful as an indication = that =20 > > clients should use the simplified stateless DHCPv6 rather than the =20 > > full DHCPv6. > >=20 > > And I would object to any deprecation on the basis that=20 > there isn't =20 > > enough operational experience to be able to make a good decision. > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:36:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhp9-0006s3-Oh; Fri, 27 May 2005 12:36:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhp8-0006rI-1a; Fri, 27 May 2005 12:36:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25276; Fri, 27 May 2005 12:36:35 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbi7x-0007Ri-EC; Fri, 27 May 2005 12:56:06 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 13E85181; Fri, 27 May 2005 12:34:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:35:35 -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: Fri, 27 May 2005 12:35:33 -0400 Message-ID: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViz18hoHkosVPZSMmenVDiSlovbAACqaaA From: "Bound, Jim" To: "Ted Lemon" , "Bernie Volz (volz)" X-OriginalArrivalTime: 27 May 2005 16:35:35.0256 (UTC) FILETIME=[1B6EB580:01C562DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 ughh. sorry know of three production servers in use Lucent, HP, and Linux version. /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 11:16 AM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; ipv6@ietf.org;=20 > Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 6:18 AM, Bernie Volz (volz) wrote: > > These changes would potentially cause some issues with any=20 > deployments > > today because the clients and servers do not support this "new" > > behavior, but it that's why it is critical we work this out ASAP. > > However, those clients, if they use the M & O bits, could continue =20 > > to do > > what they do today -- since both bits are available. It is just new > > clients with old servers that may have issues. >=20 > I may not have a full sense of the market, but FWIW I don't get the =20 > impression that backwards compatibility for servers is a huge issue =20 > at the moment. So a simplifying change at this point would be a =20 > good thing. There have certainly been times in the past when we've =20 > regretted our failure to make simplifying changes in the DHCP =20 > protocol back when it wasn't widely deployed. (Or at least=20 > I have - =20 > I can't really speak for other members of the wg.) >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:42:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhvE-0008Hm-OZ; Fri, 27 May 2005 12:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhvB-0008Ge-Kr; Fri, 27 May 2005 12:42:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26299; Fri, 27 May 2005 12:42:51 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiE1-0007hS-8z; Fri, 27 May 2005 13:02:21 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 8E81A16C; Fri, 27 May 2005 12:42:44 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:41:57 -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: Fri, 27 May 2005 12:41:55 -0400 Message-ID: <936A4045C332714F975800409DE09240541502@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcViu/KLWFDdMW0aQBKaNLO1HM9CWgAHYKxAAABPUvA= From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 27 May 2005 16:41:57.0288 (UTC) FILETIME=[FF242A80:01C562DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: [dhcwg] RE: purpose of m/o bit 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 hmmm I wonder if part of the confusion is for prefix delegation to happen maybe that should be signaled by the m bit. The o bit or its function should be pristine to mean only use dhc for configuration data like dns, link information, services information etc. when m bit set it is client/server implementation defined by admins for dhc whether stateless dhc is used or full dhc? /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Bound, Jim > Sent: Friday, May 27, 2005 12:32 PM > To: Ralph Droms; matthew.ford@bt.com > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 > m =3D=3D use dhc for addresses, o =3D=3D use dhc for just = configuration bow do > you do this with one bit? neither m or o not set says don't use dhc. > thus my reason for ternary. >=20 > thx > /jim=20 >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > > On Behalf Of Ralph Droms > > Sent: Friday, May 27, 2005 8:59 AM > > To: matthew.ford@bt.com > > Cc: dhcwg@ietf.org; ipv6@ietf.org > > Subject: [dhcwg] RE: purpose of m/o bit > >=20 > > Mat - thanks for your review and input. I specified the=20 > two bits only > > for backward compatibility with existing implementations. > >=20 > > I imagine we could design a specification that retains one bit and > > deprecates the other, with rules about the appearance of the depre > > backward compatibility. At least, this spec would need a note > > explaining why there are two bits in the spec and=20 > > recommending that new > > implementations use, for example, just the M bit. > >=20 > > - Ralph > >=20 > > On Fri, 2005-05-27 at 13:41 +0100, matthew.ford@bt.com wrote: > > > Ralph Droms wrote: > > >=20 > > > > Seems to me I'm hearing two requirements out of this thread: > > > >=20 > > > > 1) Ability to indicate to a host "DHCP is not available=20 > > on this link", > > > > with the expectation that the host won't send any=20 > DHCP messages > > > >=20 > > > > 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 > > > >=20 > > > > 1 is a requirement in scenarios with limited resources (e.g., > > > > wireless), where polling for DHCP is unacceptable. 2 is a > > > > requirement to avoid timeout delays or other complexity=20 > in getting > > > > ICB reply when=20 > > > > host would > > > > prefer HCB reply. > > > >=20 > > > > If I've got that right, we can meet the two requirements=20 > > with a couple > > > > of small updates to existing specs: > > > >=20 > > > > 1) If an RA is received with the M and/or the O bit is set, DHCP > > > > service is available over the link through which the RA > > > > was received > > > > (no differentiation between HCB and ICB DHCP) > > > >=20 > > > > 2) If a DHCP server receives an HCB request (Solicit)=20 > but can only > > > > supply an ICB, the server can respond with the ICB=20 > > reply (note that > > > > according RFC 3115, the server would respond with an=20 > "HCB-nak" > > > > [Advertise containing only an error code]) > > > >=20 > > > > In addition to meeting the requirements, these updates=20 > > are mostly (if > > > > not entirely) operationally compatible with existing clients and > > > > servers.=20 > > >=20 > > > I completely agree with this analysis and support=20 > proceeding on this > > > basis. But it does beg the question, why do we need two=20 > > bits to signal a > > > binary condition? > > >=20 > > > -- Mat > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 12:45:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhxO-0000vH-Cs; Fri, 27 May 2005 12:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbhxL-0000se-4T; Fri, 27 May 2005 12:45:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26761; Fri, 27 May 2005 12:45:04 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiGA-0007ow-Mq; Fri, 27 May 2005 13:04:34 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id D2A11169; Fri, 27 May 2005 12:44:57 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 12:44:04 -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: Fri, 27 May 2005 12:44:02 -0400 Message-ID: <936A4045C332714F975800409DE09240541507@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi2r9DQ5A0CMcRRJ+iCYXM4pW08gAAE68A From: "Bound, Jim" To: "Ted Lemon" X-OriginalArrivalTime: 27 May 2005 16:44:04.0330 (UTC) FILETIME=[4ADD3CA0:01C562DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 sure but breaking production code has to jump a higher bar regardless and I am not convinced that all have come to good set of statements and assumptions what those bits mean right now and I think that is prudent before changing them. prefix delegation puts another and new variable in the analysis I think now. /jim=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, May 27, 2005 12:40 PM > To: Bound, Jim > Cc: Bernie Volz (volz); dhcwg@ietf.org; Iljitsch van Beijnum;=20 > ipv6@ietf.org; Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > > ughh. sorry know of three production servers in use Lucent, HP, and > > Linux version. > > >=20 > That's not what I mean. The point is that it's early days, and =20 > updating servers isn't a hard problem. My point is that I don't =20 > know of any widespread deployments we'd be breaking right now, not =20 > that there are no implementations. >=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 Fri May 27 12:48:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbi0j-0003BT-JY; Fri, 27 May 2005 12:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbi0h-0003BL-4i; Fri, 27 May 2005 12:48:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27477; Fri, 27 May 2005 12:48:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiJV-000822-L3; Fri, 27 May 2005 13:08:03 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 May 2005 09:48:23 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RGlhmM016376; Fri, 27 May 2005 09:48:17 -0700 (PDT) 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); Fri, 27 May 2005 12:48:11 -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: Fri, 27 May 2005 12:48:10 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi2tNXlKPR+n/8TluP1pvW3uJSzwAAFS7Q From: "Bernie Volz \(volz\)" To: "Ted Lemon" , "Bound, Jim" X-OriginalArrivalTime: 27 May 2005 16:48:11.0844 (UTC) FILETIME=[DE64E040:01C562DB] X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 Also, the servers aren't impacted by the M/O bits. They don't use them. Though changing the DHCPv6 protocol as we've contemplated, would impact the servers and the clients. But if you're currently deploying with either the M set or the O set, there is no problem. Sure, if a client talks to a new server it might get other configuration parameters in an Advertise, but I doubt that would cause it to fail (it would likely just ignore the parameters). The only situation where these changes would impact clients is if a new client communicates with an old server. Since the old server won't send other configuration parameters. So, yes the servers would need to be upgraded in order to use newer clients. - Bernie=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, May 27, 2005 12:40 PM > To: Bound, Jim > Cc: Bernie Volz (volz); dhcwg@ietf.org; Iljitsch van Beijnum;=20 > ipv6@ietf.org; Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > > ughh. sorry know of three production servers in use Lucent, HP, and > > Linux version. > > >=20 > That's not what I mean. The point is that it's early days, and =20 > updating servers isn't a hard problem. My point is that I don't =20 > know of any widespread deployments we'd be breaking right now, not =20 > that there are no implementations. >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 13:21:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbiW5-0001Dz-FF; Fri, 27 May 2005 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbiW4-0001Dt-4z for ipv6@megatron.ietf.org; Fri, 27 May 2005 13:21:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00259 for ; Fri, 27 May 2005 13:20:57 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18j1e3dShtBQNtgtDMwDpkmhWn659QULao=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbiot-0000T4-1v for ipv6@ietf.org; Fri, 27 May 2005 13:40:28 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DbiVx-0004Cz-Bk for ; Fri, 27 May 2005 19:20:57 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtps id 1DbiVw-0005MC-4L; Fri, 27 May 2005 19:20:52 +0200 Message-ID: <429756F3.5040707@tm.uka.de> Date: Fri, 27 May 2005 19:20:51 +0200 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: IPv6 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -19.5 (-------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Mark Doll , TM-RO2 , Roland Bless Subject: Comment on RFCs 2461bis and 2462bis 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 everybody, one comment concerning RFCs 2461bis and 2462bis. The documents define that a node must delay... - its initial Router Solicitation after interface (re-) initialization (D1) [RFC 2461bis] - joining the solicited-nodes multicast address after interface (re-) initialization (D2) [RFC 2462bis] - joining the solicited-nodes multicast address before starting DAD triggered on a multicast RA (D3) [RFC 2462bis] RFC 2461bis explicitly mentions, in section 6.3.7, that the delay for Router Solicitations (D1) can be omitted by mobile nodes. This helps to detect movement more quickly. However, RFC 2462bis has no equivalent rule with respect to the delay for sending a MLD Report (D2, D3). So, when it comes to configuring a new address through DAD, nodes must still delay joining the solicited-nodes multicast address, which in turn delays DAD. As a consequence, mobile nodes can get a RA quickly by avoiding (D1), but they are still stuck with (D2) or (D3). This prevents rapid re-attachment after a handover. Besides, RFC 2461bis's relaxation of (D1) for mobile nodes has no effect---at least not to the extent it should---if you still have (D2) and (D3). To make this story short: Even at the risk of suggesting something that has been discussed on the IPv6 mailing list before, I propose to remove delays (D2) and (D3) in RFC 2462bis for mobile nodes. I know there is an issue with contention when a multicast RA triggers multiple MLD Reports. The question is how likely that is, and how much more often delays (D2) and (D3) would be disruptive to mobile nodes. Bye for now, - Christian PS: One side note about recovery: Nodes will recover from MLD Report collisions. But if an MLD Report fails, and two nodes simultaneously attempt to configure the same IPv6 address at that time, this duplication won't be detected. And nodes would not recover either. PPS: As an alternative to relaxing (D2) and (D3), one may think about a relaxation on the requirement to join the solicited-nodes multicast address *prior* to DAD. After all, DAD does work if the initiator has not joined the group, because any NAs will be sent to the all-nodes multicast address. The only issue is a situation in which two nodes attempt to configure the same address at the same time. The question is how likely that is... PPPS: As far as I see, the ODAD draft does not mention or tackle the delay for MLD Reports either. Maybe that should be changed, too. Nick? -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 13:31:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbigG-0003Rq-DP; Fri, 27 May 2005 13:31:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbigD-0003RJ-O6; Fri, 27 May 2005 13:31:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01069; Fri, 27 May 2005 13:31:26 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbiz2-0000m9-9G; Fri, 27 May 2005 13:50:58 -0400 Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4RHUHGJ021508; Fri, 27 May 2005 10:30:17 -0700 (PDT) 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 j4RHUDxi548994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 May 2005 10:30:14 -0700 (PDT) Message-ID: <42975938.8060700@sun.com> Date: Fri, 27 May 2005 10:30:32 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> <1117148729.7913.26.camel@localhost.localdomain> In-Reply-To: <1117148729.7913.26.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: purpose of m/o bit 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 Ralph Droms wrote: > Seems to me I'm hearing two requirements out of this thread: > > 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 > - 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 I the case where the network admin wants to do stateless address autoconfiguration and has DHCP available for ICB, how inefficient will the above be? Wouldn't this mean that the hosts which are implemented to handle HCB as well as ICB, would always try with a Solicit i.e. they would end up doing a 4 packet DHCP exchange. Had the host known that HCB was not available, a 2 packet exchange would have been sufficient. Thinking about hosts moving between different links, the difference between 4 and 2 packets for DHCP ICB might matter. Hence my question how useful it would be to have 3) Ability for the host to find out from the RA that it doesn't need to bother with HCB since only ICB is available on the network. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 13:41:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbipy-0005VD-Hr; Fri, 27 May 2005 13:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbipu-0005UA-4O for ipv6@megatron.ietf.org; Fri, 27 May 2005 13:41:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02459 for ; Fri, 27 May 2005 13:41:29 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbj8j-0001E2-8X for ipv6@ietf.org; Fri, 27 May 2005 14:00:58 -0400 Received: by rproxy.gmail.com with SMTP id a41so412631rng for ; Fri, 27 May 2005 10:41:27 -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:content-transfer-encoding:content-disposition:references; b=BtEtjmO+OoalkF0k63/yxlmTqW2eDqOllzQjSeizcQC+L0RQPiW77UG8k3SyPxZltfX/J1fmOCNZUx5/aoyUWKyphZUErXENVSdlmd6HafPTjs3rIL71Mep9d+TCt6G16i41LeD8WjRC09xeu1WHodmpJk1xIuvP8cCtiATtqgQ= Received: by 10.38.5.73 with SMTP id 73mr3791897rne; Fri, 27 May 2005 10:41:25 -0700 (PDT) Received: by 10.38.161.75 with HTTP; Fri, 27 May 2005 10:41:24 -0700 (PDT) Message-ID: <10e14db20505271041115527ee@mail.gmail.com> Date: Fri, 27 May 2005 23:11:24 +0530 From: Syam Madanapalli To: ipv6@ietf.org, dhcwg@ietf.org In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , Iljitsch van Beijnum , jinmei@isl.rdc.toshiba.co.jp, "Bernie Volz \(volz\)" , Ted Lemon , "Bound, Jim" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Syam Madanapalli 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 Isn't it such a long idscussion a proof for the confusion in understanding the M/O bits? Instead of leaving the discussion here, thinking that there is no confusion or be fore taking any radical changes (either discarding M or O or both flags,= or=20 making changes to the DHCPv6 protocols), it is better to document the inted= ed=20 use of M/O flags as an informational document, so that we will have uniform= =20 implementations in th future. I am sure this (intended use of M/O flags) is very obvious for some people here, but definitely help many others. Also this information will be handy for the implementer. - Syam -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 13:42:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbiqj-0005qM-2e; Fri, 27 May 2005 13:42:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbiqi-0005qD-0b; Fri, 27 May 2005 13:42:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02647; Fri, 27 May 2005 13:42:19 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbj9U-0001Hy-Oq; Fri, 27 May 2005 14:01:48 -0400 Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4RHgDGJ001380; Fri, 27 May 2005 10:42:13 -0700 (PDT) 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 j4RHgCtw553061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 May 2005 10:42:13 -0700 (PDT) Message-ID: <42975C06.8010200@sun.com> Date: Fri, 27 May 2005 10:42:30 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit 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 Bernie Volz (volz) wrote: > Why? > > If we update the DHCPv6 protocol to allow "other configuration" options > to be returned in an Advertise for a Solicit, Information-Request/Reply > and Solicit/Advertise are then essentially the same in a stateless > DHCPv6 environment (though the Solicit does require a client identifier > and likely may require a IA_* option). > > Note that this will require changes to 3315 and 3736 - since stateless > servers will need to respond to Solicits with Advertises. Do we know we can change DHCPv6 that way without causing compatibility problems for any existing DHCPv6 clients? I can see such a client not expecting configuration information in the advertise message. Or are we assuming that there are no 3315 DHCP clients out there? There might also be compatibility issues on the server, since this appears to assume that a 3736-only server will handle Solicit messages, unless the clients have some logic to fallback from using Solicit to using Information-Requests after a few attempts. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:13:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjId-0001su-4h; Fri, 27 May 2005 14:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjIa-0001sY-Mw; Fri, 27 May 2005 14:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08153; Fri, 27 May 2005 14:11:07 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjbQ-000347-0U; Fri, 27 May 2005 14:30:37 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:10:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RIARlU013850; Fri, 27 May 2005 14:10:55 -0400 (EDT) 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); Fri, 27 May 2005 14:09:56 -0400 Received: from 161.44.65.252 ([161.44.65.252]) 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 ; Fri, 27 May 2005 18:09:56 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 14:10:25 -0400 From: Ralph Droms To: Erik Nordmark In-Reply-To: <42975938.8060700@sun.com> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> <1117148729.7913.26.camel@localhost.localdomain> <42975938.8060700@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 14:10:24 -0400 Message-Id: <1117217425.26540.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 18:09:56.0686 (UTC) FILETIME=[49E85EE0:01C562E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: purpose of m/o bit 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 - the idea is to allow a client to initiate either HCB or ICB with the same message, which turns into a 4 message exchange for HCB (2 messages w/ "rapid commit") or 2 message exchange for ICB. - Ralph On Fri, 2005-05-27 at 10:30 -0700, Erik Nordmark wrote: > Ralph Droms wrote: > > Seems to me I'm hearing two requirements out of this thread: > > > > 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 > > - 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 > > I the case where the network admin wants to do stateless address > autoconfiguration and has DHCP available for ICB, how inefficient will > the above be? > > Wouldn't this mean that the hosts which are implemented to handle HCB as > well as ICB, would always try with a Solicit i.e. they would end up > doing a 4 packet DHCP exchange. Had the host known that HCB was not > available, a 2 packet exchange would have been sufficient. > > Thinking about hosts moving between different links, the difference > between 4 and 2 packets for DHCP ICB might matter. > > Hence my question how useful it would be to have > 3) Ability for the host to find out from the RA that it doesn't need to > bother with HCB since only ICB is available on the network. > > Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:13:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjL0-0002AQ-Pi; Fri, 27 May 2005 14:13:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjKw-00029o-EK; Fri, 27 May 2005 14:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08593; Fri, 27 May 2005 14:13:33 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbjdl-000388-Sz; Fri, 27 May 2005 14:33:03 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 649A817F; Fri, 27 May 2005 14:13:17 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:12:24 -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: Fri, 27 May 2005 14:12:22 -0400 Message-ID: <936A4045C332714F975800409DE09240541571@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi41F2StgiEOyIQqWMb30BI0w02gABC6DQ From: "Bound, Jim" To: "Syam Madanapalli" , , X-OriginalArrivalTime: 27 May 2005 18:12:24.0611 (UTC) FILETIME=[A213EF30:01C562E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , Iljitsch van Beijnum , "Bernie Volz \(volz\)" , Ted Lemon , "Ralph Droms \(rdroms\)" , jinmei@isl.rdc.toshiba.co.jp Subject: RE: [dhcwg] RE: purpose of m/o bit 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 at least have discussion where all agree for sure. not clear a document is needed if we can put it in dhc or possibly biz update to 2462 yet again :----) /jim=20 > -----Original Message----- > From: Syam Madanapalli [mailto:smadanapalli@gmail.com]=20 > Sent: Friday, May 27, 2005 1:41 PM > To: ipv6@ietf.org; dhcwg@ietf.org > Cc: Ted Lemon; Bound, Jim; Iljitsch van Beijnum; Ralph Droms=20 > (rdroms); Bernie Volz (volz); Thomas Narten;=20 > jinmei@isl.rdc.toshiba.co.jp > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > Isn't it such a long idscussion a proof for the confusion in > understanding the M/O > bits? Instead of leaving the discussion here, thinking that there is > no confusion or > be fore taking any radical changes (either discarding M or O=20 > or both flags, or=20 > making changes to the DHCPv6 protocols), it is better to=20 > document the inteded=20 > use of M/O flags as an informational document, so that we=20 > will have uniform=20 > implementations in th future. I am sure this (intended use of M/O > flags) is very > obvious for some people here, but definitely help many others. Also > this information > will be handy for the implementer. >=20 > - Syam >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:24:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjVP-0005QF-Oe; Fri, 27 May 2005 14:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjVK-0005Pf-N7; Fri, 27 May 2005 14:24:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09737; Fri, 27 May 2005 14:24:17 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbjo9-0003T9-Um; Fri, 27 May 2005 14:43:47 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:24:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RINQ5U018277; Fri, 27 May 2005 14:24:04 -0400 (EDT) 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); Fri, 27 May 2005 14:24:03 -0400 Received: from 161.44.65.252 ([161.44.65.252]) 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 ; Fri, 27 May 2005 18:24:02 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 14:24:31 -0400 From: Ralph Droms To: Syam Madanapalli In-Reply-To: <10e14db20505271041115527ee@mail.gmail.com> References: <8E296595B6471A4689555D5D725EBB21338D3D@xmb-rtp-20a.amer.cisco.com> <10e14db20505271041115527ee@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 14:24:31 -0400 Message-Id: <1117218271.26540.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 18:24:03.0134 (UTC) FILETIME=[426E15E0:01C562E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , dhcwg@ietf.org, "Bound, Jim" , jinmei@isl.rdc.toshiba.co.jp, Ted Lemon Subject: Re: [dhcwg] RE: purpose of m/o bit 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 But the discussion says nothing about how complex the underlying issues are. I think there is significant room for simplification (but no more simplification than necessary!), especially if we set aside preconceptions about the M/O bits and look at what we've learned through discussion, implementation and deployment planning. - Ralph On Fri, 2005-05-27 at 23:11 +0530, Syam Madanapalli wrote: > Isn't it such a long idscussion a proof for the confusion in > understanding the M/O > bits? Instead of leaving the discussion here, thinking that there is > no confusion or > be fore taking any radical changes (either discarding M or O or both flags, or > making changes to the DHCPv6 protocols), it is better to document the inteded > use of M/O flags as an informational document, so that we will have uniform > implementations in th future. I am sure this (intended use of M/O > flags) is very > obvious for some people here, but definitely help many others. Also > this information > will be handy for the implementer. > > - Syam -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:25:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjWk-0005cP-Md; Fri, 27 May 2005 14:25:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjWj-0005bs-0e; Fri, 27 May 2005 14:25:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09813; Fri, 27 May 2005 14:25:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbjpY-0003Us-3s; Fri, 27 May 2005 14:45:13 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:25:34 -0400 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 j4RIPD5E018809; Fri, 27 May 2005 14:25:31 -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); Fri, 27 May 2005 14:25:18 -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: Fri, 27 May 2005 14:25:18 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi44Fak3O3YdWHTx6k5y/j/63PvwABJ7ww From: "Bernie Volz \(volz\)" To: "Erik Nordmark" X-OriginalArrivalTime: 27 May 2005 18:25:18.0990 (UTC) FILETIME=[6FA4CAE0:01C562E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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: As I believe Spock said - "there are always possibilities". But realisticly, do you expect any old client to check for these "other configuration" parameters and if they got them, what might they do? Drop the packet? Well, that is what the client would essentially have done anyway since it got no addresses. So, while a poorly implemented client might well crash, I can't really see that being likely and it would be worth it to get that client fixed as quickly as possible since it doesn't adhere to the "be liberal in what you receive" IETF "rule". If people are really concerned about this, we can always add a DHCPv6 option to the Solicit that tells the server "I'm a new client and am able to receive other configuration parameters even if you're not going to give me any addresses." Thus, the old servers would ignore this option and new servers would know that it is OK to do this. Regarding the other issue, why would a stateless only client ever say "Oh, I'll send Solicit instead of Information-Request"? If they did that today, they wouldn't get very far. Sure, if a new client sent Solicits and the old stateless server ignored them, there would be a problem (as I pointed out in previous message(s)). But, I suspect that the magnitude of that problem is small. And, the sooner we resolve these issues and update the specs, the fewer implementations will have issues (I know of a bunch of implementations under development so if we wait much longer ...). An old client that sends Solicits to a stateless server won't get very far today anyway, so we can ignore that case. And, if it fails over to use Information-Request, great. - Bernie > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com]=20 > Sent: Friday, May 27, 2005 1:43 PM > To: Bernie Volz (volz) > Cc: Iljitsch van Beijnum; ipv6@ietf.org; dhcwg@ietf.org;=20 > Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > Bernie Volz (volz) wrote: > > Why? > >=20 > > If we update the DHCPv6 protocol to allow "other=20 > configuration" options > > to be returned in an Advertise for a Solicit,=20 > Information-Request/Reply > > and Solicit/Advertise are then essentially the same in a stateless > > DHCPv6 environment (though the Solicit does require a=20 > client identifier > > and likely may require a IA_* option). > >=20 > > Note that this will require changes to 3315 and 3736 -=20 > since stateless > > servers will need to respond to Solicits with Advertises. >=20 > Do we know we can change DHCPv6 that way without causing=20 > compatibility=20 > problems for any existing DHCPv6 clients? I can see such a client not=20 > expecting configuration information in the advertise message. > Or are we assuming that there are no 3315 DHCP clients out there? >=20 > There might also be compatibility issues on the server, since this=20 > appears to assume that a 3736-only server will handle Solicit=20 > messages,=20 > unless the clients have some logic to fallback from using Solicit to=20 > using Information-Requests after a few attempts. >=20 > Erik >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:41:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjmO-0000zp-Lk; Fri, 27 May 2005 14:41:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjmM-0000zI-FN; Fri, 27 May 2005 14:41:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11630; Fri, 27 May 2005 14:41:53 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbk5B-0003zR-TM; Fri, 27 May 2005 15:01:23 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 21E0415B; Fri, 27 May 2005 14:39:20 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:40:52 -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: Fri, 27 May 2005 14:40:50 -0400 Message-ID: <936A4045C332714F975800409DE0924054158F@tayexc14.americas.cpqcorp.net> Thread-Topic: Where do we do this work: purpose of m/o bit Thread-Index: AcVi44Fak3O3YdWHTx6k5y/j/63PvwABJ7wwAADDAvA= From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 18:40:52.0749 (UTC) FILETIME=[9C351BD0:01C562EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Cc: Subject: Where do we do this work: purpose of m/o bit 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 Do we need to continue cross posting and we should decide where we sort this out IPv6 or DHC. =20 My suggestion is the bits need to be understood for ND and Addrconf thus lets get this done in the IPv6 WG. That would make job of what DHC has to do easy. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:48:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjsd-0002O0-B1; Fri, 27 May 2005 14:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjsb-0002Ni-HS for ipv6@megatron.ietf.org; Fri, 27 May 2005 14:48:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12781 for ; Fri, 27 May 2005 14:48:20 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkBR-0004Hc-2E for ipv6@ietf.org; Fri, 27 May 2005 15:07:50 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0760818D for ; Fri, 27 May 2005 14:45:49 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:48:00 -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: Fri, 27 May 2005 14:47:59 -0400 Message-ID: <936A4045C332714F975800409DE09240541591@tayexc14.americas.cpqcorp.net> Thread-Topic: ND+Addrconf Parameters to state use of dhc on a link Thread-Index: AcVi7JqqRZMl2mp+RVecq52k78sIpA== From: "Bound, Jim" To: X-OriginalArrivalTime: 27 May 2005 18:48:00.0811 (UTC) FILETIME=[9B5A2FB0:01C562EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Subject: ND+Addrconf Parameters to state use of dhc on a link 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 Lets do one step at a time so assumptions are known first. Do we want bits within ND packet to inform nodes on a link to use or not use dhc?=20 This not to dicuss the placement, use of, or semantics of the bits. I think consensus is from the beginning that we do believe as a WG this is required? Any dissentiion that ND packet should not inform nodes of this on a link? If so why? thanks /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjud-00037S-NR; Fri, 27 May 2005 14:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjub-00036e-C6; Fri, 27 May 2005 14:50:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13237; Fri, 27 May 2005 14:50:24 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkDR-0004Qh-Q1; Fri, 27 May 2005 15:09:54 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 1642218B; Fri, 27 May 2005 14:47:54 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:49:53 -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: Fri, 27 May 2005 14:49:52 -0400 Message-ID: <936A4045C332714F975800409DE09240541593@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVi67csnJmM6yf0QHSzndYwluxIEwAAPqJQ From: "Bound, Jim" To: "Ted Lemon" , "Bernie Volz (volz)" X-OriginalArrivalTime: 27 May 2005 18:49:53.0556 (UTC) FILETIME=[DE8DB540:01C562EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Iljitsch van Beijnum , dhcwg@ietf.org, Erik Nordmark , ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 input is dhcpv6 implementation and deployment state is quite flexible for this topic and code affect and config/admin affect. If we move to unicast instead of multicast for dhc answer would be different ok. /jim=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 2:40 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org; Ralph Droms (rdroms); Erik Nordmark;=20 > ipv6@ietf.org; Iljitsch van Beijnum > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote: > > If people are really concerned about this, we can always=20 > add a DHCPv6 > > option to the Solicit that tells the server "I'm a new client and am > > able to receive other configuration parameters even if you're not =20 > > going > > to give me any addresses." Thus, the old servers would ignore this > > option and new servers would know that it is OK to do this. >=20 > DHCPv6 is not a full standard. I don't think it's widely deployed =20 > at this point. I would rather take the risk, as you suggest, than =20 > add an extra protocol to negotiate whether we can do this - it's =20 > extra logic in the server that will be needed for zero clients two =20 > years from now - just another piece of unused code that could be =20 > buggy, because it's never used, and thus could be an avenue=20 > of attack =20 > for some enterprising young script kiddie. >=20 > The time to get conservative about breaking clients by sending them =20 > unexpected responses will come, but it hasn't come yet, IMHO. I =20 > haven't heard anything to contradict this - has anyone else? >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 14:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjv4-0003Fy-0g; Fri, 27 May 2005 14:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbjv0-0003Ff-EX; Fri, 27 May 2005 14:50:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13363; Fri, 27 May 2005 14:50:49 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkDp-0004TE-RU; Fri, 27 May 2005 15:10:19 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 14:50:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4RInw5Q026459; Fri, 27 May 2005 14:50:34 -0400 (EDT) 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); Fri, 27 May 2005 14:50:31 -0400 Received: from 161.44.65.252 ([161.44.65.252]) 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 ; Fri, 27 May 2005 18:50:31 +0000 Received: from localhost.localdomain by email.cisco.com; 27 May 2005 14:51:00 -0400 From: Ralph Droms To: "Bound, Jim" In-Reply-To: <936A4045C332714F975800409DE0924054158F@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924054158F@tayexc14.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 27 May 2005 14:51:00 -0400 Message-Id: <1117219860.26540.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 27 May 2005 18:50:31.0741 (UTC) FILETIME=[F55046D0:01C562EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: Where do we do this work: purpose of m/o bit 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 Jim - it would be great to sort this out in one group or the other. But I think the eventual solution will require input from both ipv6 and dhc WGs, so we might have to continue the cross-posting or set up a short- lived mailing list just for this discussion. - Ralph On Fri, 2005-05-27 at 14:40 -0400, Bound, Jim wrote: > Do we need to continue cross posting and we should decide where we sort > this out IPv6 or DHC. > > My suggestion is the bits need to be understood for ND and Addrconf thus > lets get this done in the IPv6 WG. That would make job of what DHC has > to do easy. > > /jim > > -------------------------------------------------------------------- > 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 May 27 14:56:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbk04-0007gK-QG; Fri, 27 May 2005 14:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbk02-0007fn-Ef; Fri, 27 May 2005 14:56:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14872; Fri, 27 May 2005 14:56:01 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkIs-0004yH-UO; Fri, 27 May 2005 15:15:31 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id A8DE013C; Fri, 27 May 2005 14:53:31 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 14:55:15 -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: Fri, 27 May 2005 14:55:14 -0400 Message-ID: <936A4045C332714F975800409DE09240541596@tayexc14.americas.cpqcorp.net> Thread-Topic: Where do we do this work: purpose of m/o bit Thread-Index: AcVi7PutDOmKB+EIRDSKU0jVK2QiLgAADnSw From: "Bound, Jim" To: "Ralph Droms" X-OriginalArrivalTime: 27 May 2005 18:55:15.0575 (UTC) FILETIME=[9E7DE870:01C562ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: Where do we do this work: purpose of m/o bit 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 Ralph, I think there are two parts. This has affect to neighbor discovery protocol too. That is clearly the IPv6 WG. It also then affect to Addrconf and that is IPv6 WG. I just sent mail to IPv6 taking this as baby step to first ask a very basic assumption question. I want to see how that simple mail plays out. This has been going on too long and part of the problem is pure communications vectors not being done logically simply for discussion. If others want the cross posting that is fine I just asked the question and would like to hear what people think that is all. thanks /jim=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Friday, May 27, 2005 2:51 PM > To: Bound, Jim > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: Where do we do this work: purpose of m/o bit >=20 > Jim - it would be great to sort this out in one group or the=20 > other. But > I think the eventual solution will require input from both=20 > ipv6 and dhc > WGs, so we might have to continue the cross-posting or set up a short- > lived mailing list just for this discussion. >=20 > - Ralph >=20 > On Fri, 2005-05-27 at 14:40 -0400, Bound, Jim wrote: > > Do we need to continue cross posting and we should decide=20 > where we sort > > this out IPv6 or DHC. =20 > >=20 > > My suggestion is the bits need to be understood for ND and=20 > Addrconf thus > > lets get this done in the IPv6 WG. That would make job of=20 > what DHC has > > to do easy. > >=20 > > /jim > >=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 Fri May 27 15:09:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkDS-0002tt-Mf; Fri, 27 May 2005 15:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkDQ-0002sm-3v; Fri, 27 May 2005 15:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16792; Fri, 27 May 2005 15:09:50 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkWF-0005Nx-VM; Fri, 27 May 2005 15:29:21 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id DFD06191; Fri, 27 May 2005 15:07:18 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:09:06 -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: Fri, 27 May 2005 15:09:05 -0400 Message-ID: <936A4045C332714F975800409DE092405415AB@tayexc14.americas.cpqcorp.net> Thread-Topic: Implementation change affect from m and o bits Thread-Index: AcVi7401rK7TWYgKR/CwWrOGn5kLkA== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:09:06.0856 (UTC) FILETIME=[8DF95280:01C562EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Subject: Implementation change affect from m and o bits 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 question asked is what is the implementation affect. I know something about this hands on from coding it :--) If it was just dhc client and dhc server that I will input can be changed rather easily to support a change in syntax and semantics, and as dhc for ipv6 is now just being deployed it will not be that painful to rev if that is what the dhc and ipv6 wgs want to do. That is my input on that end. Now if we started whacking basic architecture of dhc for IPv6 then I would give you a different answer. =20 But the m and o bit also affect the code path that scans the ND packet and looks for the m and o bit as other bits in ND. Then there is code from addrconf to help resolve the if condtions of what to do or not do from the m and o bit. This code base can be integrated and varys from implementer to implementer from discussions with many of you over the years when we talk about implementing our beloved IETF specifications. This part of the m and o bit code is long before the dhc client begins processing and the code to do dhc client procesing for ipv6. If we get rid of the m and o bit it will affect three pieces of code: ND, Addrconf Selection, and then dhc. So it is not just changing dhc code. So if we change the bits or alter them this is what we are facing. I think before we know whether this is worth the change or doing it we need to be sure what we want to do and then and only then can determine implementation decision. The other option is keep the bits as is and then change how they are used or verify how they are used and that will only affect the indirection for Addrconf and dhc most likely. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 15:14:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkHd-0003y3-UQ; Fri, 27 May 2005 15:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkHb-0003xR-DW; Fri, 27 May 2005 15:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17432; Fri, 27 May 2005 15:14:09 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkaS-0005V7-77; Fri, 27 May 2005 15:33:40 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0F83E1A2; Fri, 27 May 2005 15:11:35 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:13:39 -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: Fri, 27 May 2005 15:13:38 -0400 Message-ID: <936A4045C332714F975800409DE092405415B3@tayexc14.americas.cpqcorp.net> Thread-Topic: ND+Addrconf Parameters to state use of dhc on a link Thread-Index: AcVi44Fak3O3YdWHTx6k5y/j/63PvwABJ7wwAADDAvAAASHEIA== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:13:40.0017 (UTC) FILETIME=[30CA6210:01C562F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: Subject: ND+Addrconf Parameters to state use of dhc on a link 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 think Ted makes good point. I am now sending this to both lists. I will build my filter in a minute :--). So all respond to this mail with dissention if you have any. Resent text: Lets do one step at a time so assumptions are known first. Do we want bits within ND packet to inform nodes on a link to use or not use dhc?=20 This not to dicuss the placement, use of, or semantics of the bits. I think consensus is from the beginning that we do believe as a WG this is required? Any dissentiion that ND packet should not inform nodes of this on a link? If so why? thanks /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 15:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkRo-0006x9-QR; Fri, 27 May 2005 15:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkRn-0006wc-GP; Fri, 27 May 2005 15:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18661; Fri, 27 May 2005 15:24:41 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbkkc-0005nY-Bz; Fri, 27 May 2005 15:44:10 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 67F661A4; Fri, 27 May 2005 15:22:09 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:24:21 -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: Fri, 27 May 2005 15:24:20 -0400 Message-ID: <936A4045C332714F975800409DE092405415BB@tayexc14.americas.cpqcorp.net> Thread-Topic: Semantics of Stateful Bits for the Client Thread-Index: AcVi8a6ejz+kcwHqQ6yX9jDBY2V31w== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:24:22.0133 (UTC) FILETIME=[AF858250:01C562F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: Subject: Semantics of Stateful Bits for the Client 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 If we believe we will inform clients to use or not use dhc and I am going to guess all agree with that so we have to multitask here in cyberspace. What semantic conditions do we inform clients about when we inform them to use dhc via ND packet. Points from the many mails are as follows. 1. use dhc only to obtain addresses 2. use dhc only to obtain configuration parameters 3. use dhc to do 1 and 2. Does prefix delegation requires its own condidtion?=20 Is prefix delegation covered by 1 and then is it dhc process to decide what is done? /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 15:27:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkUs-0007J2-OL; Fri, 27 May 2005 15:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbkUr-0007HX-4d; Fri, 27 May 2005 15:27:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18889; Fri, 27 May 2005 15:27:51 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbkng-0005qV-Ow; Fri, 27 May 2005 15:47:22 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 98E3E1A0; Fri, 27 May 2005 15:25:20 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 15:27:39 -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: Fri, 27 May 2005 15:27:37 -0400 Message-ID: <936A4045C332714F975800409DE092405415C2@tayexc14.americas.cpqcorp.net> Thread-Topic: Addconf bit not set at all in ND Thread-Index: AcVi8iRA6pF57hNoSlOJZ5QRU3URLg== From: "Bound, Jim" To: , X-OriginalArrivalTime: 27 May 2005 19:27:39.0485 (UTC) FILETIME=[252708D0:01C562F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: Subject: Addconf bit not set at all in ND 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 There also came up the case that addrconf is not set at all. The client receives no advice from router or ND as to what they should do. 1. We leave this to industry to determine based on deployment and implementations. This is our default today. 2. We state default is start dhc client. I vote for #1 per Tim Hartrick email. Others? /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 16:28:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblRx-0007Jw-3P; Fri, 27 May 2005 16:28:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblRu-0007Jo-Su; Fri, 27 May 2005 16:28:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01088; Fri, 27 May 2005 16:28:53 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dblkm-0001eP-Fc; Fri, 27 May 2005 16:48:24 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4RKRpmJ016777 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 22:27:51 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D2D@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338D2D@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C118F33-76F6-488D-96D4-D3EFA8AA4C71@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 27 May 2005 22:27:39 +0200 To: Bernie Volz ((volz)) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Re: [dhcwg] RE: purpose of m/o bit 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 27-mei-2005, at 18:16, Bernie Volz ((volz)) wrote: >> 1 1 send Solicit send Information-Request > But what happens if the stateful server is down and stateless is > running? Buy more servers?? Some solutions are simple. :-) > Though I would never recommend that a link have both of these > types of servers. I would assume that both types of servers wouldn't existing alongside. AFAIK, there is no reason that a server that does full DHCPv6 couldn't/shouldn't do answer stateless DHCPv6 queries as well. Only when there is no need for stateful DHCPv6, it would make sense to run a light-weight stateless server. For instance, on a residential type router. > We could easily resolve this by adjusting the DHCPv6 protocol as > proposed (ie, stateful and stateless servers can respond to Solicit > with > Advertise with just other configuration parameters). Wouldn't that put RFC 3376 out of business? > We really want to communicate three states in terms of the DHCPv6 > service available on the link: No DHCPv6, Stateful DHCPv6, and > Stateless > DHCPv6 -- not 4. Ok, I agree with you that those three are needed. I also think the fourth one is slightly useful, but that one isn't very imporant. Do we all agree that no DHCPv6/stateful DHCPv6/stateless DHCPv6 are all useful? > Note that this says nothing about what a client > supports (if the client can only do stateless, that's all it can do!). Right. > Clients would run DHCPv6 unless the "No DHCPv6" is set. :-) > So, perhaps we should deprecate M=1 *AND* O=1. Clients should > always run > DHCPv6 if EITHER M = 1 OR O = 1. If M=1, run stateful (if supported, > stateless otherwise). If O=1, run stateless (if supported). It already says in RFC 246x that O = 1 is implied when M = 1. I.e., the useful combinations are: M = 0, O = 0 M = 0, O = 1 M = 1, O = x > In any case, I would still fix the DHCPv6 protocol to allow Advertises > to return other configuration parameters when no addresses are > available > AND to require stateless DHCPv6 servers to support Solicit (with > Advertise with just other configuration parameters). I'm offering no opinions on that one. > I still believe deprecating the 2nd bit (O) is better. Disagree for various reasons. The way I see it, people may be interested in implementing clients and servers that just do stateless DHCPv6 (RFC 3376). Sure, it's probably doable to make any combination of stateful/stateless server and stateful/stateless client do something reasonable, but I'm convinced that knowing in advance (by virtue of the M = 0, O = 1 combination) on both the server and the client that we'll be stateless makes for much simpler implemenations. It also makes troubleshooting easier: with the O bit present, the M bit is a reliable indicator whether or not hosts will take addresses from a DCHPv6 server. Without the O bit the M bit is overloaded and the only way to determine whether the DHCPv6 server also supplies addresses (and possibly messes this job up) is by looking at a DHCPv6 interaction. Predictability is a highly regarded commodity in operational environments. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 16:41:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dble6-0001fo-HQ; Fri, 27 May 2005 16:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbldz-0001eX-Gp; Fri, 27 May 2005 16:41:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02128; Fri, 27 May 2005 16:41:21 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dblwp-0001wi-C1; Fri, 27 May 2005 17:00:53 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 May 2005 16:41:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4RKf1lE027200; Fri, 27 May 2005 16:41:10 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 16:40:57 -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: Fri, 27 May 2005 16:40:57 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB21338DCF@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Semantics of Stateful Bits for the Client Thread-Index: AcVi8a6ejz+kcwHqQ6yX9jDBY2V31wAClV/g From: "Bernie Volz \(volz\)" To: "Bound, Jim" , , X-OriginalArrivalTime: 27 May 2005 20:40:57.0793 (UTC) FILETIME=[62BF9310:01C562FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: [dhcwg] Semantics of Stateful Bits for the Client 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 Does anyone really see any value in 1? And this is always possible - just don't configure the DHCPv6 server with any configuration parameters to send out. - Bernie=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Bound, Jim > Sent: Friday, May 27, 2005 3:24 PM > To: ipv6@ietf.org; dhcwg@ietf.org > Subject: [dhcwg] Semantics of Stateful Bits for the Client >=20 > If we believe we will inform clients to use or not use dhc and I am > going to guess all agree with that so we have to multitask here in > cyberspace. >=20 > What semantic conditions do we inform clients about when we=20 > inform them > to use dhc via ND packet. >=20 > Points from the many mails are as follows. >=20 > 1. use dhc only to obtain addresses >=20 > 2. use dhc only to obtain configuration parameters >=20 > 3. use dhc to do 1 and 2. >=20 > Does prefix delegation requires its own condidtion?=20 >=20 > Is prefix delegation covered by 1 and then is it dhc process to decide > what is done? >=20 > /jim >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 16:45:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblhV-0002HH-2T; Fri, 27 May 2005 16:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DblhQ-0002G8-Of; Fri, 27 May 2005 16:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02431; Fri, 27 May 2005 16:44:54 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbm0C-00022G-96; Fri, 27 May 2005 17:04:26 -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 j4RKimjO014010; Fri, 27 May 2005 14:44:48 -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 j4RKil6R640553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 May 2005 13:44:47 -0700 (PDT) Message-ID: <429786D1.3050407@sun.com> Date: Fri, 27 May 2005 13:45:05 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit 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 Bernie Volz (volz) wrote: > But realisticly, do you expect any old client to check for these "other > configuration" parameters and if they got them, what might they do? Drop > the packet? Well, that is what the client would essentially have done > anyway since it got no addresses. So, while a poorly implemented client > might well crash, I can't really see that being likely and it would be > worth it to get that client fixed as quickly as possible since it > doesn't adhere to the "be liberal in what you receive" IETF "rule". If we ignore DHCP client implementations which crash when they receive an unexpected option, what is the worst case of a RFC 3315 client in this case? Is it just to ignore the options in the Advertise message and proceed to send a Request message? That wouldn't be a big deal to me. > Regarding the other issue, why would a stateless only client ever say > "Oh, I'll send Solicit instead of Information-Request"? If they did that > today, they wouldn't get very far. The server compatibility issue isn't about today. The issue I see if we recommend that clients (which implement both RFC 3315 and 3736) always send a Solicit (when some bit is set in the RA telling it to use DHCP), then such a client will not interoperate with currently deployed 3736 DHCP servers. My understanding is that there is some deployment of 3736 DHCP servers (to do prefix delegation and DNS configuration, etc). Do we know that there is zero deployment of 3736 servers today? If we need to handle those, it seems like either - the client needs to try a few Solicits first, and if that fails, try an Information-Request. (Or try them in parallel??) - Have some indication in the RA that only 3736 service is available on the network, so that the client can do the Information-Request only. The second alternative seems simpler to me. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 20:28:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbpBi-0001L1-1K; Fri, 27 May 2005 20:28:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbpBf-0001KU-TZ; Fri, 27 May 2005 20:28:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17335; Fri, 27 May 2005 20:28:22 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbpUY-0006TX-Gi; Fri, 27 May 2005 20:47:55 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel10.hp.com (Postfix) with ESMTP id C997A256F; Fri, 27 May 2005 17:28:19 -0700 (PDT) Received: from HM701792 (hm701791.cup.hp.com [15.13.133.85]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id FAA12767; Sat, 28 May 2005 05:56:18 +0530 (IST) Message-Id: <200505280026.FAA12767@iconsrv6.india.hp.com> From: "Anil Kumar Reddy" To: "'Iljitsch van Beijnum'" Date: Fri, 27 May 2005 17:28:12 -0700 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: <9BEDF265-04AC-4150-82DF-CDF0C2B905F9@muada.com> Thread-Index: AcVhHgy0xmeslgg2QaeJJ+I31qaP+AB/VZnw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, 'IETF IPv6 Mailing List' Subject: RE: [dhcwg] Re: purpose of m/o bit 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 : From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] : On Behalf Of Iljitsch van Beijnum : Sent: Wednesday, May 25, 2005 2:43 AM : : [Crossposted to dhcwg even though I'm not on that list, as : people there may be able to add some useful insights.] : All of this, coupled with the fact that, AFAIK, no OS : implements DHCPv6, means that there is essentially zero : experience with DHCPv6 in the operational community. This : means that at this time, there is little point in asking the : operational community what should happen with the M and O bits. FYI - If I am not too late on this: HP-UX supports DHCPv6 implementation - conforming to RFC3315. I don't intend to deviate the topic, but I thought this info may be useful for you with respect to operational community. -- Anil -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri May 27 22:55:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbrU2-0000Gg-2c; Fri, 27 May 2005 22:55:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbrTz-0000G6-Rs; Fri, 27 May 2005 22:55:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25809; Fri, 27 May 2005 22:55:25 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbrmu-0000j2-S8; Fri, 27 May 2005 23:15:01 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8FDA0E3; Fri, 27 May 2005 22:52:53 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 22:55:15 -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: Fri, 27 May 2005 22:55:12 -0400 Message-ID: <936A4045C332714F975800409DE0924054164A@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] Semantics of Stateful Bits for the Client Thread-Index: AcVi8a6ejz+kcwHqQ6yX9jDBY2V31wAClV/gAAx3aCA= From: "Bound, Jim" To: "Bernie Volz (volz)" , , X-OriginalArrivalTime: 28 May 2005 02:55:15.0125 (UTC) FILETIME=[AC5C7E50:01C56330] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: [dhcwg] Semantics of Stateful Bits for the Client 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 > Does anyone really see any value in 1? >=20 > And this is always possible - just don't configure the DHCPv6 server > with any configuration parameters to send out. I don't and never did. I think it odd too. I will share my view of one reason why this happened. Realize my priority is always compromise and move forward, unless it breaks major code base, or significant architecture flaw for the Internet end-to-end model I just cannot accept. Thus, I did support the specs moving forward, and my last statement below says the same thing if we do not change this set of bits. Early on work for IPv6 within the infrastructure driver individuals and from the very first Addrconnf presentation discussion on IPv6 at the IETF, the consenus of that then group was the Internet would be better with stateless and not have go to stateful servers for anything. But, clearly dhc from v4 demonstrated how useful configuration parameters are to a user on a link,and other basic services. But, the consenus then was ok lets make sure we add function to permit some form of stateful configuration (dhc was not even considered at this time by most the eventual mechanism which I never got) for parameters for the link, but separate that option from configuration. Thus, two bits for stateful. One for obtaining addresses, another to obtain configuration parameters. Another more noble reason was the idea to separate stateful address semantics, becuase stateless is the default, from the need for other configuration parameters, and break this perceived problem down into multiple levels of indirection within the link architecture to obtain addresses and configuration parameters as separate functions. I think the entire notion should in theory be changed to just use dhc for addresses+parameters, and let dhc determine, as suggested above with one example. if addresses or parameters are to be provided to the nodes. Prefix delegation is a new function I won't go into in this thread (which I think is wonderful as a note). But we must use caution by removing the ND m+o bits and the affect to ND and Addrconf code base per my other email. Getting consenus on if we change the initial thinking model and a lot of code base (servers, clients, routers etc.), from the non-dhc code affect, on this list I think is key to moving forward. Or we must make the semantics work with the bit-space we have, which I will bet is what we will have to do for multiple reasons and not all technical. My .25 cents, /jim > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > > On Behalf Of Bound, Jim > > Sent: Friday, May 27, 2005 3:24 PM > > To: ipv6@ietf.org; dhcwg@ietf.org > > Subject: [dhcwg] Semantics of Stateful Bits for the Client > >=20 > > If we believe we will inform clients to use or not use dhc and I am > > going to guess all agree with that so we have to multitask here in > > cyberspace. > >=20 > > What semantic conditions do we inform clients about when we=20 > > inform them > > to use dhc via ND packet. > >=20 > > Points from the many mails are as follows. > >=20 > > 1. use dhc only to obtain addresses > >=20 > > 2. use dhc only to obtain configuration parameters > >=20 > > 3. use dhc to do 1 and 2. > >=20 > > Does prefix delegation requires its own condidtion?=20 > >=20 > > Is prefix delegation covered by 1 and then is it dhc=20 > process to decide > > what is done? > >=20 > > /jim > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=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 Sat May 28 02:53:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbvC9-0005vV-DP; Sat, 28 May 2005 02:53:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbvC7-0005vN-6Z for ipv6@megatron.ietf.org; Sat, 28 May 2005 02:53:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29045 for ; Sat, 28 May 2005 02:53:13 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbvV3-0004z7-M4 for ipv6@ietf.org; Sat, 28 May 2005 03:12:50 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EE69215218; Sat, 28 May 2005 15:55:41 +0900 (JST) Date: Sat, 28 May 2005 15:53:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Christian Vogt In-Reply-To: <429756F3.5040707@tm.uka.de> References: <429756F3.5040707@tm.uka.de> 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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Mark Doll , TM-RO2 , Roland Bless , IPv6 Subject: Re: Comment on RFCs 2461bis and 2462bis 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, 27 May 2005 19:20:51 +0200, >>>>> Christian Vogt said: > one comment concerning RFCs 2461bis and 2462bis. The documents define > that a node must delay... I'd like to begin with a general note... > To make this story short: Even at the risk of suggesting something that > has been discussed on the IPv6 mailing list before, I propose to remove > delays (D2) and (D3) in RFC 2462bis for mobile nodes. I know there is > an issue with contention when a multicast RA triggers multiple MLD > Reports. The question is how likely that is, and how much more often > delays (D2) and (D3) would be disruptive to mobile nodes. Yes, we've already discussed this sort of thing, probably several times. The basic consensus was we would not introduce any changes that can affect non-mobile nodes just for helping mobile nodes, at least within the scope of 2461bis/2462bis, due to the "conservative" nature of the recycling process. See, for example, discussions at 58th IETF at: http://www.ietf.org/proceedings/03nov/137.htm In this sense, we'd not justify a logic like "disruption without random delay should be very rare and eliminating the delay would help mobile nodes very much. So let's introduce the optimization". What we need to justify the change is a proof that the change never affects existing (non mobile in this case) implementations, not a doubt about the probability of disruption. In fact, the change about "D1" in rfc2461bis was introduced with very careful wording for not disrupting existing implementations. Also, we should note that other "radical" changes like changing RA frequency (to every 50ms) or removing random delay before sending RAs were rejected, mainly based on the "conservative" principle. Note that this policy is limited to 2461bis/2462bis. We can still discuss, implement, or even standardize any new ideas *as a separate work item*. And, indeed, the mobile IPv6 specification introduces a new RA frequency, and optimistic DAD is now going to become a PS. Someday, when we have enough operational experience on the new ideas, those may be incorporated into the base specification. But clearly it's not now. I hope this explanation helps avoid having the "101th" discussion about a new change proposal into 246[12]bis based on the "but isn't it unlikely?" type of logic. Now going to specific points... > - its initial Router Solicitation after interface (re-) initialization > (D1) [RFC 2461bis] > - joining the solicited-nodes multicast address after interface (re-) > initialization (D2) [RFC 2462bis] > - joining the solicited-nodes multicast address before starting DAD > triggered on a multicast RA (D3) [RFC 2462bis] Hmm..., regarding D2, it seems we can apply the same approach as D1 in 2461bis. Regarding D3, I'm not sure if we can make it for 2462bis, since this event is not (necessarily) triggered by moving a link, and it may be difficult to find a prudent condition like the one described in 2461bis for D1. Recall that our first priority in 2462bis is to avoid disruption for existing implementations, not to provide mobile nodes an easy way out. Besides, even if we remove D3, the mobile node will still face a delay in this case, because the responding router will impose a random delay before sending an RA. So, I'm negative about removing D3 from rfc2462bis. Is this decision okay for you? Assuming the answer is yes for now, do we still want to remove D2? As you pointed out, just removing D2 may not necessarily help mobile nodes, so the change would still be incomplete. Considering the current status of the document (already passed an IESG last call, and now waiting for IESG approval), I'm personally reluctant to introduce the change at this stage. But if many others also want the change (and no one objects to that), I'll try to revise the draft once again. 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 Sat May 28 03:10:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbvSS-0000hI-3K; Sat, 28 May 2005 03:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbvSP-0000h9-9J for ipv6@megatron.ietf.org; Sat, 28 May 2005 03:10:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29785 for ; Sat, 28 May 2005 03:10:03 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbvlL-0005Ih-Jh for ipv6@ietf.org; Sat, 28 May 2005 03:29:40 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1F8B215218; Sat, 28 May 2005 16:12:46 +0900 (JST) Date: Sat, 28 May 2005 16:10:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Soliman, Hesham" 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: 2461bis update 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, 24 May 2005 10:04:25 -0400, >>>>> "Soliman, Hesham" said: > I submitted an updated revision of 2461bis which includes > the resolutions that were agreed on by the WG in the last meeting > (the SLLAO thread). It also includes fixes for the comments Tatuya > raised on the last version. Sorry, it's me again... I guess "bullet 2" (update APPENDIX C based on a recent discussion about "RS with srcaddr but w/o SLLAO") mentioned in the following is not addressed in the 03 version: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04472.html (you seem to have agreed with the change: http://www1.ietf.org/mail-archive/web/ipv6/current/msg04473.html ) 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 Sat May 28 03:17:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbvZy-0002F5-61; Sat, 28 May 2005 03:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbvZw-0002Et-5I for ipv6@megatron.ietf.org; Sat, 28 May 2005 03:17:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00274 for ; Sat, 28 May 2005 03:17:50 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbvsq-0005Td-0M for ipv6@ietf.org; Sat, 28 May 2005 03:37:27 -0400 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8DBEA15218; Sat, 28 May 2005 16:20:30 +0900 (JST) Date: Sat, 28 May 2005 16:18:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: H.Soliman@flarion.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: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipv6@ietf.org Subject: rfc2461bis issue 257 resolved? 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 Hello, I happen to have noticed that issue 257 for rfc2461 (Eliminate random delay in RA transmission) may not be actually resolved, at least at the issue tracker: https://rt.psg.com/Ticket/Display.html?id=257 (anyone can get read-only access with user/pass=ietf/ietf) According to the tracker, the status was once changed from new to resolved, but then the following comment was added: Very sorry for the confusion. This text belongs to a different issue. Eliminating the random delay is NOT rejected. and this is actually the last message recorded at the tracker. This seems far from the "resolved" status...what is the real current status of this issue? 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 Sat May 28 10:31:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2LF-0004tV-UK; Sat, 28 May 2005 10:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbgZM-0006kR-Rc; Fri, 27 May 2005 11:16:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20096; Fri, 27 May 2005 11:16:14 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbgsA-0005Yl-Pf; Fri, 27 May 2005 11:35:44 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id ABC5356870; Fri, 27 May 2005 08:16:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338CA6@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4AFD5C60-F460-41C8-B2D8-387A15B009FD@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Fri, 27 May 2005 08:15:51 -0700 To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 May 2005 10:31:07 -0400 Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit 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 May 27, 2005, at 6:18 AM, Bernie Volz (volz) wrote: > These changes would potentially cause some issues with any deployments > today because the clients and servers do not support this "new" > behavior, but it that's why it is critical we work this out ASAP. > However, those clients, if they use the M & O bits, could continue > to do > what they do today -- since both bits are available. It is just new > clients with old servers that may have issues. I may not have a full sense of the market, but FWIW I don't get the impression that backwards compatibility for servers is a huge issue at the moment. So a simplifying change at this point would be a good thing. There have certainly been times in the past when we've regretted our failure to make simplifying changes in the DHCP protocol back when it wasn't widely deployed. (Or at least I have - I can't really speak for other members of the wg.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 28 10:31:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2LH-0004tw-3M; Sat, 28 May 2005 10:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbhsf-0007b0-Ca; Fri, 27 May 2005 12:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25883; Fri, 27 May 2005 12:40:14 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbiBS-0007Zm-RH; Fri, 27 May 2005 12:59:45 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 3F8A556883; Fri, 27 May 2005 09:39:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Fri, 27 May 2005 09:39:52 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 May 2005 10:31:08 -0400 Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit 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 May 27, 2005, at 9:35 AM, Bound, Jim wrote: > ughh. sorry know of three production servers in use Lucent, HP, and > Linux version. > That's not what I mean. The point is that it's early days, and updating servers isn't a hard problem. My point is that I don't know of any widespread deployments we'd be breaking right now, not that there are no implementations. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 28 10:31:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2LI-0004uN-Ry; Sat, 28 May 2005 10:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbjkO-0000hl-VJ; Fri, 27 May 2005 14:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11539; Fri, 27 May 2005 14:39:51 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbk3E-0003xO-NB; Fri, 27 May 2005 14:59:22 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7F39656898; Fri, 27 May 2005 11:39:41 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C095C5C-F1A7-45C0-B227-1E3D5DEC35FA@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Fri, 27 May 2005 11:39:40 -0700 To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 May 2005 10:31:08 -0400 Cc: dhcwg@ietf.org, "Ralph Droms \(rdroms\)" , Erik Nordmark , ipv6@ietf.org, Iljitsch van Beijnum Subject: Re: [dhcwg] RE: purpose of m/o bit 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 May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote: > If people are really concerned about this, we can always add a DHCPv6 > option to the Solicit that tells the server "I'm a new client and am > able to receive other configuration parameters even if you're not > going > to give me any addresses." Thus, the old servers would ignore this > option and new servers would know that it is OK to do this. DHCPv6 is not a full standard. I don't think it's widely deployed at this point. I would rather take the risk, as you suggest, than add an extra protocol to negotiate whether we can do this - it's extra logic in the server that will be needed for zero clients two years from now - just another piece of unused code that could be buggy, because it's never used, and thus could be an avenue of attack for some enterprising young script kiddie. The time to get conservative about breaking clients by sending them unexpected responses will come, but it hasn't come yet, IMHO. I haven't heard anything to contradict this - has anyone else? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 28 10:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2LK-0004uo-0f; Sat, 28 May 2005 10:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbk4n-00016l-Gl; Fri, 27 May 2005 15:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15416; Fri, 27 May 2005 15:00:56 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbkNb-0005Au-DU; Fri, 27 May 2005 15:20:26 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 1421D56883; Fri, 27 May 2005 12:00:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <936A4045C332714F975800409DE09240541596@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE09240541596@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Fri, 27 May 2005 12:00:43 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 May 2005 10:31:08 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org, Ralph Droms Subject: Re: [dhcwg] RE: Where do we do this work: purpose of m/o bit 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 May 27, 2005, at 11:55 AM, Bound, Jim wrote: > If others want the cross posting that is fine I just asked the > question > and would like to hear what people think that is all. Seems like part of what's going on is that we needed to have this discussion cross-posted a year or three ago, so it's probably better to keep cross-posting now and let the people who don't want to hear about it put up a filter to delete messages on the thread. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 28 10:31:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2LL-0004vF-6y; Sat, 28 May 2005 10:31:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dblvq-0005VY-KB; Fri, 27 May 2005 16:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03661; Fri, 27 May 2005 16:59:48 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbmEh-0002Pj-KE; Fri, 27 May 2005 17:19:20 -0400 Received: from [66.93.162.115] (dsl093-162-115.tus1.dsl.speakeasy.net [66.93.162.115]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 567635687E; Fri, 27 May 2005 13:59:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB21338DCF@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21338DCF@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Date: Fri, 27 May 2005 13:59:36 -0700 To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 May 2005 10:31:08 -0400 Cc: dhcwg@ietf.org, ipv6@ietf.org, "Bound, Jim" Subject: Re: [dhcwg] Semantics of Stateful Bits for the Client 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 May 27, 2005, at 1:40 PM, Bernie Volz (volz) wrote: > Does anyone really see any value in 1? > > And this is always possible - just don't configure the DHCPv6 server > with any configuration parameters to send out. 1 seems a bit odd, yes. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat May 28 13:55:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5WZ-000651-0E; Sat, 28 May 2005 13:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5WX-00063p-4H; Sat, 28 May 2005 13:55:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20752; Sat, 28 May 2005 13:54:57 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc5pX-0003j9-1j; Sat, 28 May 2005 14:14:40 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id BB17420000A6; Sat, 28 May 2005 13:54:45 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 28 May 2005 13:54:45 -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: Sat, 28 May 2005 13:54:44 -0400 Message-ID: <936A4045C332714F975800409DE092405416AC@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVjkjpupLshrK2+S0u7/cUCDWVeDAAHAzUA From: "Bound, Jim" To: "Ted Lemon" X-OriginalArrivalTime: 28 May 2005 17:54:45.0748 (UTC) FILETIME=[555C0340:01C563AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" Subject: RE: [dhcwg] RE: purpose of m/o bit 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 for dhcp yes but for IPv6 it is now widespread in multiple target markets. /jim=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 12:40 PM > To: Bound, Jim > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; ipv6@ietf.org;=20 > Bernie Volz (volz); Ralph Droms (rdroms) > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > > ughh. sorry know of three production servers in use Lucent, HP, and > > Linux version. > > >=20 > That's not what I mean. The point is that it's early days, and =20 > updating servers isn't a hard problem. My point is that I don't =20 > know of any widespread deployments we'd be breaking right now, not =20 > that there are no implementations. >=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 Sun May 29 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 1DcEyg-0008M6-BY; Sun, 29 May 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 1DcEye-0008M1-1S for ipv6@megatron.ietf.org; Sun, 29 May 2005 00:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25431 for ; Sun, 29 May 2005 00:00:36 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcFHl-00076x-Qn for ipv6@ietf.org; Sun, 29 May 2005 00:20:26 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2545DA3 for ; Sun, 29 May 2005 00:00:16 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 29 May 2005 00:00:16 -0400 Message-Id: <20050529040016.2545DA3@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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.14% | 28 | 21.46% | 163904 | jim.bound@hp.com 12.95% | 18 | 12.66% | 96664 | jinmei@isl.rdc.toshiba.co.jp 9.35% | 13 | 8.99% | 68638 | rdroms@cisco.com 7.91% | 11 | 8.59% | 65630 | volz@cisco.com 6.47% | 9 | 7.63% | 58239 | h.soliman@flarion.com 7.19% | 10 | 6.12% | 46756 | iljitsch@muada.com 4.32% | 6 | 4.42% | 33788 | narten@us.ibm.com 2.88% | 4 | 3.17% | 24204 | internet-drafts@ietf.org 3.60% | 5 | 2.38% | 18142 | ted.lemon@nominum.com 2.88% | 4 | 2.39% | 18259 | erik.nordmark@sun.com 2.16% | 3 | 2.45% | 18744 | greg.daley@eng.monash.edu.au 2.16% | 3 | 2.06% | 15735 | soohong.park@samsung.com 2.16% | 3 | 2.05% | 15639 | kempf@docomolabs-usa.com 1.44% | 2 | 2.46% | 18764 | richard_woundy@cable.comcast.com 1.44% | 2 | 1.51% | 11523 | tim@mentat.com 1.44% | 2 | 1.35% | 10280 | john.loughney@nokia.com 1.44% | 2 | 1.25% | 9517 | margaret@thingmagic.com 1.44% | 2 | 0.89% | 6780 | rdasilva@va.rr.com 0.72% | 1 | 1.22% | 9331 | suresh.krishnan@ericsson.ca 0.72% | 1 | 1.03% | 7882 | brian@innovationslab.net 0.72% | 1 | 0.73% | 5611 | chvogt@tm.uka.de 0.72% | 1 | 0.69% | 5239 | brc@zurich.ibm.com 0.72% | 1 | 0.64% | 4923 | bob.hinden@nokia.com 0.72% | 1 | 0.63% | 4834 | tjc@ecs.soton.ac.uk 0.72% | 1 | 0.62% | 4705 | matthew.ford@bt.com 0.72% | 1 | 0.57% | 4327 | juha.wiljakka@nokia.com 0.72% | 1 | 0.57% | 4319 | sra+ipng@hactrn.net 0.72% | 1 | 0.55% | 4199 | smadanapalli@gmail.com 0.72% | 1 | 0.49% | 3769 | sakreddy@india.hp.com 0.72% | 1 | 0.45% | 3439 | jari.arkko@kolumbus.fi --------+------+--------+----------+------------------------ 100.00% | 139 |100.00% | 763784 | 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 Sun May 29 13:36:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcRiX-0006FK-74; Sun, 29 May 2005 13:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcRiW-0006FF-27 for ipv6@megatron.ietf.org; Sun, 29 May 2005 13:36:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28708 for ; Sun, 29 May 2005 13:36:51 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/cMF9G36TICYuu9GS33j3L4o020F3uY20=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcS1k-0001SW-6c for ipv6@ietf.org; Sun, 29 May 2005 13:56:45 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DcRiG-0005I0-N2; Sun, 29 May 2005 19:36:41 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtps id 1DcRiF-0004L5-DI; Sun, 29 May 2005 19:36:35 +0200 Message-ID: <4299FDA2.7040601@tm.uka.de> Date: Sun, 29 May 2005 19:36:34 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp References: <429756F3.5040707@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -19.2 (-------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: 7bit Cc: Mark Doll , TM-RO2 , Roland Bless , IPv6 Subject: Re: Comment on RFCs 2461bis and 2462bis 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 Jinmei. > Yes, we've already discussed this sort of thing, probably several > times. I was assuming this, but probably browsed the list too little diligently. I'm sorry; my mistake. > Now going to specific points... > >> - its initial Router Solicitation after interface (re-) >> initialization (D1) [RFC 2461bis] - joining the solicited-nodes >> multicast address after interface (re-) initialization (D2) [RFC >> 2462bis] - joining the solicited-nodes multicast address before >> starting DAD triggered on a multicast RA (D3) [RFC 2462bis] > > Hmm..., regarding D2, it seems we can apply the same approach as D1 > in 2461bis. As far as I see, we should either do that, or RFC 2461bis' relaxation on D1 for MNs would be useless in most situations. > Regarding D3, I'm not sure if we can make it for 2462bis, since this > event is not (necessarily) triggered by moving a link, and it may be > difficult to find a prudent condition like the one described in > 2461bis for D1. Recall that our first priority in 2462bis is to > avoid disruption for existing implementations, not to provide mobile > nodes an easy way out. > > Besides, even if we remove D3, the mobile node will still face a > delay in this case, because the responding router will impose a > random delay before sending an RA. Well, here is the scenario I am thinking of: A MN uses unsolicited RAs---neither RSs, nor link-layer triggers---to detect IP-attachment changes. Assuming that routers send their RAs every 50ms on average, which is what RFC 3775 allows them to do, this movement-detection strategy works better than sending RSs. The reason is the random delay for solicited RAs, as you say. Even if the MN would use L2 triggers, it would still have to send an RS and await the random RA-delay in order to find out the new prefix(es). So, RFC 3775's frequent (unsolicited) RAs can be leveraged for movement detection quite nicely. But when it comes to configuring the new address, the MN ends up having to wait for D2 or D3 to send the MLD Report. In other words, eliminating D1 turns out to be useless as long as D2 and D3 are still there. I guess my point is that, conceptually, RFCs 246[12]bis impose ONE SINGLE delay for the first transmitted message whenever there is a danger for contention. If an RS is the first transmitted message, the RS needs to wait (D1). If a MLD Report is the first, it will be delayed (D2). Same with the NS for DAD after a multicast RA (D3). Once the MN has awaited one of these delays, it does no longer need to await the others. Contention may happen due to simultaneous boot-up of multiple hosts, or due to synchronized DAD after a multicast RA. Unfortunately, the original wording paraphrasing these conditions encompasses the condition of a handover, which is unintentional because handovers usually don't cause contention. The goal with RFCs 246[12]bis seems to be a relaxation for the handover condition. But this goal has yet to be met: If one removes D1 for MNs, namely D1, that doesn't help unless one either removes D2 and D3 as well, or has a particular approach in mind with which a MN could get away with only one or two delays (which, or each of which, would have to be eliminated then). I know the intent is to make RFCs 246[12]bis as conservative as possible, and to move any optimization to separate documents. In fact, I do like that idea. But as things stand, either would RFCs 246[12]bis prevent certain optimizations like frequent RAs a la RFC 3775, or such optimizations would have to explicitly revoke delays defined in RFC 246[12]bis. However, if RFCs 246[12]bis had the kind of relaxation for D2 and D3 as it already has for D1, then optimizations could just refer to this relaxation, and there would be no conflict. The challenge would therefore be to paraphrase the condition in which the relaxation could be applied, i.e., a wording that describes a handover, but does not include any other condition. Having said the things above, I hope I could strengthen the case for relaxing both D2 and D3 for MNs---similar to how it's already done for D1. > So, I'm negative about removing D3 from rfc2462bis. Is this decision > okay for you? Well, see above... ;) Let's put it this way: I would like to see the documents handle both D2 and D3 in the way they do with D1. But that's just my personal opinion... > Assuming the answer is yes for now, do we still want to remove D2? As > you pointed out, just removing D2 may not necessarily help mobile > nodes, so the change would still be incomplete. Right. > Considering the current status of the document (already passed an > IESG last call, and now waiting for IESG approval), I'm personally > reluctant to introduce the change at this stage. But if many others > also want the change (and no one objects to that), I'll try to revise > the draft once again. Yes, sorry for raising this so late. And thanks for your detailed response! Regards to all, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ JINMEI Tatuya wrote: >>>>>> On Fri, 27 May 2005 19:20:51 +0200, Christian Vogt >>>>>> said: > > >> one comment concerning RFCs 2461bis and 2462bis. The documents >> define that a node must delay... > > > I'd like to begin with a general note... > > >> To make this story short: Even at the risk of suggesting something >> that has been discussed on the IPv6 mailing list before, I propose >> to remove delays (D2) and (D3) in RFC 2462bis for mobile nodes. I >> know there is an issue with contention when a multicast RA triggers >> multiple MLD Reports. The question is how likely that is, and how >> much more often delays (D2) and (D3) would be disruptive to mobile >> nodes. > > > Yes, we've already discussed this sort of thing, probably several > times. The basic consensus was we would not introduce any changes > that can affect non-mobile nodes just for helping mobile nodes, at > least within the scope of 2461bis/2462bis, due to the "conservative" > nature of the recycling process. See, for example, discussions at > 58th IETF at: http://www.ietf.org/proceedings/03nov/137.htm > > In this sense, we'd not justify a logic like "disruption without > random delay should be very rare and eliminating the delay would help > mobile nodes very much. So let's introduce the optimization". What > we need to justify the change is a proof that the change never > affects existing (non mobile in this case) implementations, not a > doubt about the probability of disruption. > > In fact, the change about "D1" in rfc2461bis was introduced with very > careful wording for not disrupting existing implementations. Also, > we should note that other "radical" changes like changing RA > frequency (to every 50ms) or removing random delay before sending RAs > were rejected, mainly based on the "conservative" principle. > > Note that this policy is limited to 2461bis/2462bis. We can still > discuss, implement, or even standardize any new ideas *as a separate > work item*. And, indeed, the mobile IPv6 specification introduces a > new RA frequency, and optimistic DAD is now going to become a PS. > Someday, when we have enough operational experience on the new ideas, > those may be incorporated into the base specification. But clearly > it's not now. > > I hope this explanation helps avoid having the "101th" discussion > about a new change proposal into 246[12]bis based on the "but isn't > it unlikely?" type of logic. > > Now going to specific points... > > >> - its initial Router Solicitation after interface (re-) >> initialization (D1) [RFC 2461bis] - joining the solicited-nodes >> multicast address after interface (re-) initialization (D2) [RFC >> 2462bis] - joining the solicited-nodes multicast address before >> starting DAD triggered on a multicast RA (D3) [RFC 2462bis] > > > Hmm..., regarding D2, it seems we can apply the same approach as D1 > in 2461bis. > > Regarding D3, I'm not sure if we can make it for 2462bis, since this > event is not (necessarily) triggered by moving a link, and it may be > difficult to find a prudent condition like the one described in > 2461bis for D1. Recall that our first priority in 2462bis is to > avoid disruption for existing implementations, not to provide mobile > nodes an easy way out. > > Besides, even if we remove D3, the mobile node will still face a > delay in this case, because the responding router will impose a > random delay before sending an RA. > > So, I'm negative about removing D3 from rfc2462bis. Is this decision > okay for you? > > Assuming the answer is yes for now, do we still want to remove D2? > As you pointed out, just removing D2 may not necessarily help mobile > nodes, so the change would still be incomplete. Considering the > current status of the document (already passed an IESG last call, and > now waiting for IESG approval), I'm personally reluctant to > introduce the change at this stage. But if many others also want the > change (and no one objects to that), I'll try to revise the draft > once again. > > 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 May 29 14: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 1DcSq8-00055j-4u; Sun, 29 May 2005 14: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 1DcSq6-00055e-Gn for ipv6@megatron.ietf.org; Sun, 29 May 2005 14:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03313 for ; Sun, 29 May 2005 14:48:45 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcT9L-0002p0-E6 for ipv6@ietf.org; Sun, 29 May 2005 15:08:40 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4TImIk28399; Sun, 29 May 2005 21:48:20 +0300 Date: Sun, 29 May 2005 21:48:18 +0300 (EEST) From: Pekka Savola To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050520095504.02c65808@mailhost.iprg.nokia.com> Message-ID: References: <6.2.1.2.2.20050520095504.02c65808@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Brian Haberman , IPv6 WG Subject: Re: Update to 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, 20 May 2005, Bob Hinden wrote: > To clear what we hope is the last IESG "Discuss" comment on this document, > the AD's plan to add a note after the third paragraph in the Introduction > section (that starts with "This document describes an optional extension to > Neighbor Discovery Router Advertisement messages.....") as an RFC-Editor > note. The text is: > > Note that since these procedures are applicable to hosts only, > the forwarding algorithm used by the routers (including hosts > with enabled IP forwarding) is not affected. > > We wanted to pass this by the working group to see if any objects to this > change. We think the additional text is fine. This seems like a good clarification in general, but it wouldn't hurt if it was grounded more strongly on how it follows that routers don't use these procedures. AFAICS, the routers don't use this stuff simply because they're not supposed to listen to RAs (but having exact quote & reference would be good). -- 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 Sun May 29 15:05:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcT5t-0006q1-6O; Sun, 29 May 2005 15:05:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcT5r-0006o9-Nc; Sun, 29 May 2005 15:05:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04378; Sun, 29 May 2005 15:05:02 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcTP6-00036V-NY; Sun, 29 May 2005 15:24:58 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j4TJ4er28690; Sun, 29 May 2005 22:04:41 +0300 Date: Sun, 29 May 2005 22:04:39 +0300 (EEST) From: Pekka Savola To: Erik Nordmark In-Reply-To: <429786D1.3050407@sun.com> Message-ID: References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dhcwg@ietf.org, Iljitsch van Beijnum , ipv6@ietf.org, "Bernie Volz \(volz\)" , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] RE: purpose of m/o bit 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, 27 May 2005, Erik Nordmark wrote: > The issue I see if we recommend that clients (which implement both RFC 3315 > and 3736) always send a Solicit (when some bit is set in the RA telling it to > use DHCP), then such a client will not interoperate with currently deployed > 3736 DHCP servers. > My understanding is that there is some deployment of 3736 DHCP servers (to do > prefix delegation and DNS configuration, etc). > > Do we know that there is zero deployment of 3736 servers today? > > If we need to handle those, it seems like either > - the client needs to try a few Solicits first, and if that fails, try > an Information-Request. (Or try them in parallel??) > - Have some indication in the RA that only 3736 service is available on > the network, so that the client can do the Information-Request only. FWIW, I strongly believe we need to deal with _both_ stateless-only servers *and* clients. I'd also prefer that we would not need to extend RFC3736 to have to include (some) support for handling Solicits. -- 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 Sun May 29 23:01:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcaWs-0001nD-9N; Sun, 29 May 2005 23:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcaWp-0001n8-Ls for ipv6@megatron.ietf.org; Sun, 29 May 2005 23:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17830 for ; Sun, 29 May 2005 23:01:21 -0400 (EDT) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcaq8-0005ti-Go for ipv6@ietf.org; Sun, 29 May 2005 23:21:22 -0400 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOVC14SSCC99JJOY@vaxh.its.monash.edu.au> for ipv6@ietf.org; Mon, 30 May 2005 13:01:16 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B7377AB543; Mon, 30 May 2005 13:01:15 +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 83CCE4FB0B; Mon, 30 May 2005 13:01:15 +1000 (EST) Date: Mon, 30 May 2005 13:01:10 +1000 From: Greg Daley In-reply-to: <4299FDA2.7040601@tm.uka.de> To: Christian Vogt Message-id: <429A81F6.6090408@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: <429756F3.5040707@tm.uka.de> <4299FDA2.7040601@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7BIT Cc: Mark Doll , TM-RO2 , Roland Bless , IPv6 , jinmei@isl.rdc.toshiba.co.jp Subject: Re: Comment on RFCs 2461bis and 2462bis 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 Christian, I'll try to keep my response brief. Christian Vogt wrote: [cut] > >> Now going to specific points... >> >>> - its initial Router Solicitation after interface (re-) >>> initialization (D1) [RFC 2461bis] - joining the solicited-nodes >>> multicast address after interface (re-) initialization (D2) [RFC >>> 2462bis] - joining the solicited-nodes multicast address before >>> starting DAD triggered on a multicast RA (D3) [RFC 2462bis] >> >> >> Hmm..., regarding D2, it seems we can apply the same approach as D1 in >> 2461bis. > > > As far as I see, we should either do that, or RFC 2461bis' relaxation on > D1 for MNs would be useless in most situations. It depends on whether or not the RA can be received after RS without joining the multicast group. If the RA can be received, then it doesn't matter so much if the DAD has been performed at that time, or in the second after. Please note that RFC2461bis doesn't assume optimistic DAD, and so may allow RS transmission in this circumstance without a source address only. This means that the arriving packets may reduce movement or change detection time even if 30-70ms MIPv6 RA intervals aren't implemented. If the RA indicates that change has occurred, then we're already in front, for mobile hosts (and so perhaps the inclusion of the rule for RS's is valuable). There may be a problem if optimistic DAD is being used, and an NS/NA exchange is required to send a unicast RA back to the solicitor. In that case, a DNA document can talk about the tradeoffs between timers for MLD, DAD and RS. I don't think there's a need to change the base documents further. [cut] > > Well, here is the scenario I am thinking of: A MN uses unsolicited > RAs---neither RSs, nor link-layer triggers---to detect IP-attachment > changes. Assuming that routers send their RAs every 50ms on average, > which is what RFC 3775 allows them to do, this movement-detection > strategy works better than sending RSs. The reason is the random delay > for solicited RAs, as you say. Even if the MN would use L2 triggers, it > would still have to send an RS and await the random RA-delay in order to > find out the new prefix(es). > > So, RFC 3775's frequent (unsolicited) RAs can be leveraged for movement > detection quite nicely. But when it comes to configuring the new > address, the MN ends up having to wait for D2 or D3 to send the MLD > Report. In other words, eliminating D1 turns out to be useless as long > as D2 and D3 are still there. > The main issue here is that there's an unsolicited RA which many people may have received, and no indication of movement from L2, so the host is unsure why the change occurred. In this case, the host should be conservative in what it sends, and make use of a delay in order to prevent DAD contention with other unknown configuring hosts. The delay D1 is not applicable here (no L2 hint), but a single delay for DAD NS and MLD may be applicable as you say. I guessed that the new text in 2462bis covers this nicely, though. I'm quite happy to look at this sort of feedback making it into DNA documents though, since host movement is in scope for DNA, and potentially less directly applicable to IPv6 WG. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun May 29 23:20:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcapO-000411-Lx; Sun, 29 May 2005 23:20:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcapM-00040w-Fw for ipv6@megatron.ietf.org; Sun, 29 May 2005 23:20:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19268 for ; Sun, 29 May 2005 23:20:30 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcb8g-0006Hi-B2 for ipv6@ietf.org; Sun, 29 May 2005 23:40:31 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 29 May 2005 23:20:23 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 May 2005 23:20:19 -0400 Message-ID: Thread-Topic: rfc2461bis issue 257 resolved? Thread-Index: AcVjVVgt9TWl8ESCQM2G87l2jUVl+wBb3ouQ From: "Soliman, Hesham" To: "JINMEI Tatuya / ????" X-OriginalArrivalTime: 30 May 2005 03:20:23.0245 (UTC) FILETIME=[8418D7D0:01C564C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: rfc2461bis issue 257 resolved? fast RA issue 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 catching this. For those not familiar with the issue. There were two issues regarding=20 the RA improvement: 1. Relaxing the requirements on inter-RA intervals. This issue was = raised by=20 MIPv6.=20 2. Eliminating random delays before sending RAs.Also a request generated = by MIPv6. Issue 1) was rejected under the assumption that DNA would come up with a complete solution. I accidently sent that resolution through the = tracker for=20 issue 2), hence the apology below. However, I believe issue 2) (which = was=20 addressed in the fast RA draft) was also passed to DNA as discussed in = Seoul.=20 However, no resolution was formally sent for this issue by me.=20 I went back to the Seoul minutes to confirm but couldn't find a specific = mention of this issue, while others were specifically mentioned.=20 So, to avoid the confusion, I'd like to ask the WG whether they agree = that this=20 issue, addressed in draft-mkhalil-ipv6-fastra-04 (or later versions) = should not=20 be included in the current work of 2461bis.=20 Please send your comments on this issue. I'll wait till the end of the = week to=20 give people a chance to respond. thx, Hesham > I happen to have noticed that issue 257 for rfc2461 (Eliminate random > delay in RA transmission) may not be actually resolved, at least at > the issue tracker: > https://rt.psg.com/Ticket/Display.html?id=3D257 > (anyone can get read-only access with user/pass=3Dietf/ietf) >=20 > According to the tracker, the status was once changed from new to > resolved, but then the following comment was added: >=20 > Very sorry for the confusion. This text belongs > to a different issue. Eliminating the random > delay is NOT rejected.=20 >=20 > and this is actually the last message recorded at the tracker. This > seems far from the "resolved" status...what is the real=20 > current status > of this issue? >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=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 Mon May 30 00:42:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcc6s-0003OR-Mu; Mon, 30 May 2005 00:42:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcc6p-0003Nw-MC for ipv6@megatron.ietf.org; Mon, 30 May 2005 00:42:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22678 for ; Mon, 30 May 2005 00:42:36 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DccQ9-0007dl-I5 for ipv6@ietf.org; Mon, 30 May 2005 01:02:38 -0400 Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHA008J1D1VP6@mailout2.samsung.com> for ipv6@ietf.org; Mon, 30 May 2005 13:41:55 +0900 (KST) Received: from ep_spt01 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHA00KUUD1VMJ@ms3.samsung.com> for ipv6@ietf.org; Mon, 30 May 2005 13:41:55 +0900 (KST) Content-return: prohibited Date: Mon, 30 May 2005 04:41:53 +0000 (GMT) From: Daniel Park To: "Soliman, Hesham" Message-id: <7859348.1117428113530.JavaMail.weblogic@ep_ml07> MIME-version: 1.0 Content-type: text/plain; charset=SJIS Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20050530044153527@soohong.park X-MTR: 20050530044153527@soohong.park X-EPLocale: en_US.SJIS X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7BIT Cc: "ipv6@ietf.org" , JINMEI Tatuya / ???? Subject: Re: RE: rfc2461bis issue 257 resolved? fast RA issue X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.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 >So, to avoid the confusion, I'd like to ask the WG whether they agree that this >issue, addressed in draft-mkhalil-ipv6-fastra-04 (or later versions) should not >be included in the current work of 2461bis. It seems DNA task in my opinion, thus I support #2 to be removed from 2461bis. Thanks. Daniel (Soohong Daniel Park) Mobile Platform Laboratory. 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 Mon May 30 02:07:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcdR8-0003xf-0a; Mon, 30 May 2005 02:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcdR5-0003ww-Iz for ipv6@megatron.ietf.org; Mon, 30 May 2005 02:07:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04589 for ; Mon, 30 May 2005 02:07:38 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcdkQ-0000c2-Ii for ipv6@ietf.org; Mon, 30 May 2005 02:27:40 -0400 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LOVIISLC0294NXJS@vaxc.its.monash.edu.au> for ipv6@ietf.org; Mon, 30 May 2005 16:07:19 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A056AB543; Mon, 30 May 2005 16:07:18 +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 042CB4FB03; Mon, 30 May 2005 16:07:18 +1000 (EST) Date: Mon, 30 May 2005 16:07:12 +1000 From: Greg Daley In-reply-to: <7859348.1117428113530.JavaMail.weblogic@ep_ml07> To: soohong.park@samsung.com Message-id: <429AAD90.9040108@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: <7859348.1117428113530.JavaMail.weblogic@ep_ml07> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7BIT Cc: James Kempf , "ipv6@ietf.org" , Brett Pentland , "Soliman, Hesham" , Mohamed Khalil , JINMEI Tatuya / ???? Subject: Re: rfc2461bis issue 257 resolved? fast RA issue 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 Hesham, (Cc: FastRA authors) Daniel Park wrote: > >>So, to avoid the confusion, I'd like to ask the WG whether they agree that this >>issue, addressed in draft-mkhalil-ipv6-fastra-04 (or later versions) should not >>be included in the current work of 2461bis. > > > It seems DNA task in my opinion, thus I support #2 to be removed from 2461bis. I think it's safe to say that Fast RA has been found (by the authors?) to be a partial component of the required DNAv6 solution (actually almost all of the proposed solutions). We'll be interested in IPv6 WG members' feedback on the solution which is adopted as a DNA WG draft. So I request that the issue be removed from the 2461bis issue tracker list. 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 May 30 03:51:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcf3g-0006bL-7o; Mon, 30 May 2005 03:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcf3e-0006bG-6V for ipv6@megatron.ietf.org; Mon, 30 May 2005 03:51:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25019 for ; Mon, 30 May 2005 03:51:31 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcfMx-0002o5-96 for ipv6@ietf.org; Mon, 30 May 2005 04:11:35 -0400 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHA001HJLTFDU@mailout2.samsung.com> for ipv6@ietf.org; Mon, 30 May 2005 16:51:15 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IHA006U4LTFP6@mmp2.samsung.com> for ipv6@ietf.org; Mon, 30 May 2005 16:51:15 +0900 (KST) Date: Mon, 30 May 2005 16:51:13 +0900 From: "Soohong Daniel Park@samsung.com" In-reply-to: <429AAD90.9040108@eng.monash.edu.au> To: greg.daley@eng.monash.edu.au Message-id: <000201c564ec$5a3a3230$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Cc: 'James Kempf' , ipv6@ietf.org, 'Brett Pentland' , "'Soliman, Hesham'" , 'Mohamed Khalil' , 'JINMEI Tatuya / ????' Subject: RE: rfc2461bis issue 257 resolved? fast RA issue 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 Just clarifying. > We'll be interested in IPv6 WG members' feedback on the solution > which is adopted as a DNA WG draft. > > So I request that the issue be removed from the 2461bis issue > tracker list. Greg, are you saying that the FastRA was already accepted as DNA WG item ? I didn't include this consideration with my previous response. Just saying FastRA and 2461bis are not well matched in my opinion...Adopting FastRA as DNA WG item seems another issue. Thanks. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, 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 Mon May 30 05:21:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcgSR-0005qr-Oj; Mon, 30 May 2005 05:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcgSQ-0005qN-DR; Mon, 30 May 2005 05:21:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29523; Mon, 30 May 2005 05:21:11 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcglm-0004IS-Tw; Mon, 30 May 2005 05:41:16 -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 j4U9L6i3006464; Mon, 30 May 2005 10:21:06 +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 KAA16023; Mon, 30 May 2005 10:21:02 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j4U9L1C17807; Mon, 30 May 2005 10:21:01 +0100 Date: Mon, 30 May 2005 10:21:01 +0100 From: Tim Chown To: dhcwg@ietf.org, ipv6@ietf.org Message-ID: <20050530092101.GT13162@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, ipv6@ietf.org References: <936A4045C332714F975800409DE092405414FE@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: Re: [dhcwg] RE: purpose of m/o bit 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, May 27, 2005 at 09:39:52AM -0700, Ted Lemon wrote: > On May 27, 2005, at 9:35 AM, Bound, Jim wrote: > >ughh. sorry know of three production servers in use Lucent, HP, and > >Linux version. > > > > That's not what I mean. The point is that it's early days, and > updating servers isn't a hard problem. My point is that I don't > know of any widespread deployments we'd be breaking right now, not > that there are no implementations. We have been looking for a combined DHCPv4/DHCPv6 server platform that could run on Linux or BSD for some time, but have as yet failed to find one. This is for use in a production environment. We are aware of code from NEC and Lucent (but haven't yet seen either) and HP (seems to be for HP/UX only), there's also some Cisco functionality, and finally the sourceforge project (seems dormant for 15 months). We'd be very interested to find an enterprise using DHCPv6 in production, rather than just in a testbed. -- 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 Mon May 30 08:51:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcjkE-0000QU-U2; Mon, 30 May 2005 08:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcjkC-0000QJ-Nv; Mon, 30 May 2005 08:51:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12310; Mon, 30 May 2005 08:51:47 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dck3b-0008ML-CX; Mon, 30 May 2005 09:11:52 -0400 Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.3/8.12.9) with ESMTP id j4UCpjs7020988 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 May 2005 14:51:45 +0200 (CEST) From: Christian Schild To: dhcwg@ietf.org, ipv6@ietf.org In-Reply-To: <429786D1.3050407@sun.com> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> Content-Type: text/plain Date: Mon, 30 May 2005 14:51:44 +0200 Message-Id: <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3-1.3.101mdk Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [dhcwg] RE: purpose of m/o bit 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 Am Freitag, den 27.05.2005, 13:45 -0700 schrieb Erik Nordmark: > The issue I see if we recommend that clients (which implement both > RFC > 3315 and 3736) always send a Solicit (when some bit is set in the RA > telling it to use DHCP), then such a client will not interoperate > with > currently deployed 3736 DHCP servers. > My understanding is that there is some deployment of 3736 DHCP > servers > (to do prefix delegation and DNS configuration, etc). In my mind RFC3736 is flawed, as it's clients use an Information-Request message to initiate communication with a DHCPv6 server and not a Solicit message like RFC3513. It is _too_ lite. It would be really nice and handy to initiate either stateless or stateful DHCPv6 with the same message. If so, we wouldn't need the M/O bits anymore. In this case the client would simply initiate a(n Information) Request message and would get all the information that are available on the link, including an address or not. In the current state -- being stateful and stateless DHCPv6 two independent protocols -- we need the M/O bits as indicators for what is available on the link and to reduce the message count. So 1)we should use M/O as indicators, or 2)fix RFC3736 to understand Solicit message and then we could drop M/O. While it is more work and probably more pain, I'd prefer the latter. So long, Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 30 09:46:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dckb5-0005KJ-Jq; Mon, 30 May 2005 09:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dckb3-0005K8-G7; Mon, 30 May 2005 09:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15041; Mon, 30 May 2005 09:46:23 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DckuT-0000qR-M7; Mon, 30 May 2005 10:06:30 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4UDkNmJ062309 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 30 May 2005 15:46:23 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Mon, 30 May 2005 15:46:17 +0200 To: Christian Schild X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] RE: purpose of m/o bit 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 30-mei-2005, at 14:51, Christian Schild wrote: > In my mind RFC3736 is flawed, as it's clients use an > Information-Request message to initiate communication with a > DHCPv6 server and not a Solicit message like RFC3513. > It is _too_ lite. What is it that you want to do for which full DHCPv6 is too heavy but stateless DHCPv6 is too light? > It would be really nice and handy to initiate either stateless or > stateful DHCPv6 with the same message. I don't see a use case for this. As for the client: If a client only asks for configuration information and says it will do rapid-commit, and the server goes along with this (I'm not sure if the server can force more information than what the client asked for, IANADHCPv6Expert), you're basically doing stateless with a Solicit message. On the other hand, if you want to implement a simple client, just build one that does an Information-Request. Server: If you know in advance you're only going to receive Information- Requests, you can implement an RFC 3736 server. However, if you don't know this for sure, you'll have to implement a server that parses the entire DHCPv6 protocol, even if this server doesn't intend giving out stateful information (addresses or prefixes). So what we need is a way to make sure clients only (need to) do Information-Requests in situations where this is appropriate. Then we can build RFC 3736 light clients. If not, at least the servers and possibly also the clients need to implement the full stateful protocol. Also, as an operator I want to know whether a client is going to receive addresses over DHCPv6 in advance rather than have to wait for the client to do the DHCPv6 interaction and see what happened afterwards. > If so, we wouldn't need the M/O bits anymore. Is not needing the O bit a goal? We need the M bit regardless: trying to talk to a DHCPv6 server that isn't there wastes time and bandwidth. > So > 1)we should use M/O as indicators, or > 2)fix RFC3736 to understand Solicit message and then we could drop > M/O. > While it is more work and probably more pain, I'd prefer the latter. Why? These are perfectly well-behaved bits, they don't bite or soil the carpet. :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 30 11:16:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcm06-0005QX-4B; Mon, 30 May 2005 11:16:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcm04-0005QP-Rp; Mon, 30 May 2005 11:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21298; Mon, 30 May 2005 11:16:18 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcmJU-0002Ok-Jv; Mon, 30 May 2005 11:36:26 -0400 Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.3/8.12.9) with ESMTP id j4UFGEqH023032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 May 2005 17:16:18 +0200 (CEST) From: "Christian Schild (JOIN Project Team)" To: Iljitsch van Beijnum In-Reply-To: <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> Content-Type: text/plain Date: Mon, 30 May 2005 17:16:12 +0200 Message-Id: <1117466173.31317.167.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3-1.3.101mdk Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] RE: purpose of m/o bit 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 Am Montag, den 30.05.2005, 15:46 +0200 schrieb Iljitsch van Beijnum: > On 30-mei-2005, at 14:51, Christian Schild wrote: > > > In my mind RFC3736 is flawed, as it's clients use an > > Information-Request message to initiate communication with a > > DHCPv6 server and not a Solicit message like RFC3513. > > It is _too_ lite. > > What is it that you want to do for which full DHCPv6 is too heavy but > stateless DHCPv6 is too light? > > > It would be really nice and handy to initiate either stateless or > > stateful DHCPv6 with the same message. > > I don't see a use case for this. Assume you have a stateless server available on a link and M/O bits are missing or misconfigured. If there is a client that wants to do stateful DHCPv6 it will at first send a Solicit message. The stateless server has no idea about that message type and will not reply. Thus the client has to wait and needs a timeout before it will send out an Information Request to obtain other data. If now the server would be able to understand the Solicit Message it could answer immediately (even with the address missing) and the client does not have to wait. > As for the client: > > If a client only asks for configuration information and says it will > do rapid-commit, and the server goes along with this (I'm not sure if > the server can force more information than what the client asked for, > IANADHCPv6Expert), you're basically doing stateless with a Solicit > message. > > On the other hand, if you want to implement a simple client, just > build one that does an Information-Request. > > Server: > > If you know in advance you're only going to receive Information- > Requests, you can implement an RFC 3736 server. > > However, if you don't know this for sure, you'll have to implement a > server that parses the entire DHCPv6 protocol, even if this server > doesn't intend giving out stateful information (addresses or prefixes). You don't have to. My suggestion is just to substitute the Information Request with a Solicit Request (probably including a Rapid Commit and Option Request option) in RFC3736. This will make it more compatible with RFC3513 and both, the stateful and the stateless client, will get an answer immediately, regardless what kind of server is available. > So what we need is a way to make sure clients only (need to) do > Information-Requests in situations where this is appropriate. Then we > can build RFC 3736 light clients. If not, at least the servers and > possibly also the clients need to implement the full stateful protocol. > > Also, as an operator I want to know whether a client is going to > receive addresses over DHCPv6 in advance rather than have to wait for > the client to do the DHCPv6 interaction and see what happened > afterwards. > > > If so, we wouldn't need the M/O bits anymore. > > Is not needing the O bit a goal? > > We need the M bit regardless: trying to talk to a DHCPv6 server that > isn't there wastes time and bandwidth. > > > So > > 1)we should use M/O as indicators, or > > 2)fix RFC3736 to understand Solicit message and then we could drop > > M/O. > > > While it is more work and probably more pain, I'd prefer the latter. > > Why? > > These are perfectly well-behaved bits, they don't bite or soil the > carpet. :-) Actually, as an administrator, they might be a pain. As stated before, RA and DHCPv6 are different protocols. So when I want the hosts in my network to use DHCPv6 it is not sufficient to set up up the DHCPv6 server (and configure it properly), I also have to configure every router to send out an M/O bit. For _every_ subnet btw (which is currently something >500). So please don't use them as triggers. Using them as a hint is fine, but as stated before, this is close to useless. A little bit more motivation: In my mind, if capable, a client will always launch DHCPv6 (at least once) and will try to get additional information, be it an address or just some other information. It has to ask for some (DNS e.g.) information anyway. _Especially_ if you switch networks a lot. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 30 14:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcpTg-000709-T6; Mon, 30 May 2005 14:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcpTe-000704-VC for ipv6@megatron.ietf.org; Mon, 30 May 2005 14:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04992 for ; Mon, 30 May 2005 14:59:05 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcpn6-0006YG-FD for ipv6@ietf.org; Mon, 30 May 2005 15:19:14 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:5ce6:dabf:fcc2:de34]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D427B1521A; Tue, 31 May 2005 04:01:47 +0900 (JST) Date: Tue, 31 May 2005 03:59:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: greg.daley@eng.monash.edu.au In-Reply-To: <429A81F6.6090408@eng.monash.edu.au> References: <429756F3.5040707@tm.uka.de> <4299FDA2.7040601@tm.uka.de> <429A81F6.6090408@eng.monash.edu.au> 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: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Mark Doll , TM-RO2 , Roland Bless , IPv6 Subject: Re: Comment on RFCs 2461bis and 2462bis 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 Mon, 30 May 2005 13:01:10 +1000, >>>>> Greg Daley said: >> Well, here is the scenario I am thinking of: A MN uses unsolicited >> RAs---neither RSs, nor link-layer triggers---to detect IP-attachment >> changes. Assuming that routers send their RAs every 50ms on average, >> which is what RFC 3775 allows them to do, this movement-detection >> strategy works better than sending RSs. The reason is the random delay >> for solicited RAs, as you say. Even if the MN would use L2 triggers, it >> would still have to send an RS and await the random RA-delay in order to >> find out the new prefix(es). >> >> So, RFC 3775's frequent (unsolicited) RAs can be leveraged for movement >> detection quite nicely. But when it comes to configuring the new >> address, the MN ends up having to wait for D2 or D3 to send the MLD >> Report. In other words, eliminating D1 turns out to be useless as long >> as D2 and D3 are still there. > The main issue here is that there's an unsolicited RA which many people > may have received, and no indication of movement from L2, so the host is > unsure why the change occurred. > In this case, the host should be conservative in what it sends, and > make use of a delay in order to prevent DAD contention with other > unknown configuring hosts. Thanks, this is exactly what I'm going to explain in this message. I believe I don't need to say anything more for rejecting the elimination of D3 *in rfc2462bis*. (Again, this does not preclude future efforts for optimizing the delay further) > The delay D1 is not applicable here (no L2 hint), but a single delay > for DAD NS and MLD may be applicable as you say. > I guessed that the new text in 2462bis covers this nicely, though. I agree. If the point is to introduce a single delay for D1 and D2 (note that we cannot make the elimination of D3 for a different reason), we should be already done. 2461bis-03 reads: Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no need to delay again before sending the first Router Solicitation message. (Notice the last sentence) and rfc2462bis-08 reads: If the Neighbor Solicitation is going to be the first message to be sent from an interface after interface (re)initialization, the node SHOULD delay joining the solicited-node multicast address by a random delay [...] (Notice the "If" condition) I believe it is pretty clear that these specifications indicate a single delay only applicable to either D1 or D2. So, are we done (within the scope of 2461bis/2462bis)? 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 Mon May 30 16:23:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcqnP-0005bE-Ec; Mon, 30 May 2005 16:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcqnO-0005ah-8T; Mon, 30 May 2005 16:23:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11419; Mon, 30 May 2005 16:23:31 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcr6o-0008JE-Vz; Mon, 30 May 2005 16:43:42 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id CBFB9101; Mon, 30 May 2005 16:23:13 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 30 May 2005 16:23:13 -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: Mon, 30 May 2005 16:23:12 -0400 Message-ID: <936A4045C332714F975800409DE0924054176C@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVlKv74ewKcZEY1Tsu6qSHO7xkgVAAKdUNg From: "Bound, Jim" To: "Christian Schild (JOIN Project Team)" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 30 May 2005 20:23:13.0707 (UTC) FILETIME=[67BE2FB0:01C56555] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: RE: [dhcwg] RE: purpose of m/o bit 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 Folks, the purpose of this thread is to define the purpose of the bits for ND and addrconf not resolve how dhc works. We need to finish that first ok. The router is sending m and o bits now. What is their purpose and do they work. If we change them it affects far more than dhc. The thread to how to do this in dhc is most likely truly a dhc wg effort and not an ipv6 wg effort. Again the m or o bit are to inform clients before they even contemplate dhc within an ND packet.=20 Do we need both bits but we need one for them for sure.=20 thanks /jim=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 30 16:48:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcrBr-00082g-Ob; Mon, 30 May 2005 16:48:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcrBi-00082V-Oa; Mon, 30 May 2005 16:48:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12947; Mon, 30 May 2005 16:48:40 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcrVB-0000MJ-Bt; Mon, 30 May 2005 17:08:51 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j4UKmhmJ067473 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 30 May 2005 22:48:44 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1117466173.31317.167.camel@lemy.ipv6.uni-muenster.de> References: <8E296595B6471A4689555D5D725EBB21338D67@xmb-rtp-20a.amer.cisco.com> <429786D1.3050407@sun.com> <1117457504.31317.112.camel@lemy.ipv6.uni-muenster.de> <7DCAE37C-87BF-4606-A211-AF246420FA79@muada.com> <1117466173.31317.167.camel@lemy.ipv6.uni-muenster.de> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03841DBE-5A38-409C-AF44-48F11A1CA400@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Mon, 30 May 2005 22:48:28 +0200 To: Christian Schild (JOIN Project Team) X-Mailer: Apple Mail (2.730) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] RE: purpose of m/o bit 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 30-mei-2005, at 17:16, Christian Schild (JOIN Project Team) wrote: >>> It would be really nice and handy to initiate either stateless or >>> stateful DHCPv6 with the same message. >> I don't see a use case for this. > Assume you have a stateless server available on a link and M/O bits > are missing or misconfigured. Ah, ok, the problem is becoming clear to me. You see, I've spent the last 10 years of my life configuring routers. Routers do what I want them to do. Period. But obviously, if you live in an environment where you control the servers, but not the routers, a situation where the router _don't_ do what you want them to may not be unthinkable, or even academic. It's all a matter of perspective. > If there is a client that wants to do stateful DHCPv6 it will at first > send a Solicit message. The stateless server has no idea about that > message type and will not reply. Thus the client has to wait and needs > a timeout before it will send out an Information Request to obtain > other > data. Very true, and not a great situation. However, I don't think reducing functionality elsewhere is the answer. > If now the server would be able to understand the Solicit Message it > could answer immediately (even with the address missing) and the > client does not have to wait. Yes, a solution could be running a server that isn't strictly RFC 3736-only. > My suggestion is just to substitute the Information Request with a > Solicit Request (probably including a Rapid Commit and Option Request > option) in RFC3736. This will make it more compatible with RFC3513 and > both, the stateful and the stateless client, will get an answer > immediately, regardless what kind of server is available. If the dhc working group decides that the current stateless DHCPv6 needs improvement, I think you guys can figure that out on your own. However, speaking as someone who configures those pesky routers, I really want to be able to keep clients from initiating stateful DHCPv6, even if the server would only reply with stateless information anyway. It's a matter of predictability and debugging. (And some things that may or may not matter depending on what direction things take in the future.) >> These are perfectly well-behaved bits, they don't bite or soil the >> carpet. :-) > Actually, as an administrator, they might be a pain. > As stated before, RA and DHCPv6 are different protocols. So when I > want > the hosts in my network to use DHCPv6 it is not sufficient to set up > up the DHCPv6 server (and configure it properly), I also have to > configure every router to send out an M/O bit. For _every_ subnet > btw (which is currently something >500). > So please don't use them as triggers. Using them as a hint is fine, > but > as stated before, this is close to useless. > A little bit more motivation: > In my mind, if capable, a client will always launch DHCPv6 (at least > once) and will try to get additional information, be it an address or > just some other information. It has to ask for some (DNS e.g.) > information anyway. _Especially_ if you switch networks a lot. This is where we disagree. I feel very strongly that it's ESSENTIAL that a network administrator has a way to make hosts that aren't specially configured to act one way or another NOT do DHCPv6. If we assume the M/O bits will be used for this (we can come up with something new, of course) that means that if both these bits are set to zero, a host without special configuration does NOT do DHCPv6. I agree that in large networks, it's probably unpleasant to have to set up M and O bits properly on every router on every subnet. On the other hand, you need to install a DHCP server, or, more likely, DHCPv6 relaying, on every subnet anyway, so we shouldn't blow this out of proportion either. But it would be very helpful if routers could set the M and O bits automatically depending on some other relevant configuration. For instance, assuming that it's always possible to set the bits to a specific value manually, the default value could depend on wheter the router itself is configured to be a DHCPv6 server, or is configured as a DHCPv6 relay. In the latter case, the router could even temporarily poll the server and clear the bits if the server is dead. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 30 20:22:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcuWD-0004JH-3f; Mon, 30 May 2005 20:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcuW8-0004GC-F7; Mon, 30 May 2005 20:22:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26400; Mon, 30 May 2005 20:21:58 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcupe-0004HG-G7; Mon, 30 May 2005 20:42:10 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DcuW0-0001kv-Nd; Mon, 30 May 2005 20:21:52 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 30 May 2005 20:21:52 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'IP Version 6 Addressing Architecture' 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: - 'IP Version 6 Addressing Architecture ' 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. - Technical Summary This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-3513 "IP Version 6 Addressing Architecture". - Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. - Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. This document has been 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 Mon May 30 20:27:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcub3-0004my-Ib; Mon, 30 May 2005 20:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcuaz-0004lG-MA; Mon, 30 May 2005 20:27:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26873; Mon, 30 May 2005 20:26:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcuuV-0004P2-N2; Mon, 30 May 2005 20:47:11 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Dcuaz-0001tG-3G; Mon, 30 May 2005 20:27:01 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 30 May 2005 20:27:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ipv6 chair , ipv6 chair , Internet Architecture Board , ipv6 mailing list , RFC Editor Subject: Protocol Action: 'Default Router Preferences and More-Specific Routes' 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: - 'Default Router Preferences and More-Specific Routes ' 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. Technical Summary   This document describes an optional extension to Router   Advertisement messages for communicating default router preferences   and more-specific routes from routers to hosts. This improves the   ability of hosts to pick an appropriate router, especially when the   host is multi-homed and the routers are on different links. The   preference values and specific routes advertised to hosts require   administrative configuration; they are not automatically derived   from routing tables. Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. This document has been reviewed for the IESG by Margaret Wasserman. RFC Editor Note Dear RFC Editor, Please make the following change in section 1 (Introduction): OLD: This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router for an off-link destination. NEW: This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router for an off-link destination. Note that since these procedures are applicable to hosts only, the forwarding algorithm used by the routers (including hosts with enabled IP forwarding) is not affected. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 30 22:49:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcwpG-00057i-NV; Mon, 30 May 2005 22:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcwpC-00057d-GS for ipv6@megatron.ietf.org; Mon, 30 May 2005 22:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06210 for ; Mon, 30 May 2005 22:49:47 -0400 (EDT) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcx8i-0007PI-JW for ipv6@ietf.org; Mon, 30 May 2005 23:10:02 -0400 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id AA4FE394855; Tue, 31 May 2005 12:49:57 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id A7C96394081; Tue, 31 May 2005 12:49:56 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id 3336370D7C7; Tue, 31 May 2005 12:49:41 +1000 (EST) Date: Tue, 31 May 2005 12:49:41 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20050531024941.GC26956@zoic.org> Mail-Followup-To: ipv6@ietf.org, Thomas Narten References: <42951453.8050504@eng.monash.edu.au> <200505260103.j4Q13kX6004739@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505260103.j4Q13kX6004739@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Thomas Narten Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' 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 Thomas Narten wrote: > > I've reviewed this document and on the whole think it's fine for PS. Thanks. Sorry it's taken a little while for me to get back to you, I had a couple of other things on. It looks like the IESG assessment has been pretty positive, though. [talking here about sect 2.3 / sect 3.2 rule 4.] > Am I understanding correctly that not implementing the SHOULD > effectively negates the benefits of implementing the spec? Partly. Optimistic DAD is very much a compromise. It's trying to be backwards compatible with normal routers and hosts, and it's trying not to be too slow, unsafe or complicated. If we could have started again with a clean slate, we could have come up with something much nicer. But it wouldn't have worked with existing IPv6 infrastructure ... The problem being that we've only got half of the NS/NA mechanism available, because of the problem with sending LL address options and overriding NC entries. > Well, maybe it depends also on what one expects the first packets to > be that a node sends. I.e., if they are for non-neighbors (i.e., > off-link) and would go through the router, then that traffic would get > sent immediately. In a lot of cases, a mobile node won't care who is on its local net ... it's trying to quickly hand over from one net to another so it can keep on talking to someone on a third net, far away. So long as the new router broadcasts its LL address, OptiDAD works fine in this case. > But it appears that at least when sending to > neighbors, not implementing the SHOULDs results in no reduction in > delay. That's true. The reasons why I left it a SHOULD: a) it's not always necessary. Not all applications will care about talking to neighbours quickly. Those that don't have no need of this mechanism. b) it's not always sufficient. The router only SHOULD behave that way in a redirect. It might not, in which case we're back to waiting 1000ms anyway. c) it may be a pain to implement, and I'd rather that implementors have something implementable, rather than just doing the bits they need to do for their application and silently dropping the rest. Okay, so no points for dogma with that last one. But recognizing that this is a compromise solution, an alternative to just "set dad_transmits to zero", it seems okay to me. (the rest of the comments which came out of the IESG review seem pretty simple to address, to me. I think this means I need to start firing up -06 ... sadly, it seems unlikely that I'll be able to get funding to attend Paris, so it'll have to keep bouncing around in email ...) -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon May 30 23:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcx0w-0006a2-HV; Mon, 30 May 2005 23:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcx0p-0006Zx-2o for ipv6@megatron.ietf.org; Mon, 30 May 2005 23:01:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07091 for ; Mon, 30 May 2005 23:01:48 -0400 (EDT) Received: from zorg.st.net.au ([203.16.233.9] helo=borg.st.net.au ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcxKM-0007da-Aa for ipv6@ietf.org; Mon, 30 May 2005 23:22:02 -0400 Received: from localhost (localhost [127.0.0.1]) by borg.st.net.au (Postfix) with ESMTP id 9C0A739442A; Tue, 31 May 2005 13:02:00 +1000 (EST) Received: from anchovy.zoic.org (static-2.241.240.220.dsl.comindico.com.au [220.240.241.2]) by borg.st.net.au (Postfix) with ESMTP id B76633940BF; Tue, 31 May 2005 13:01:59 +1000 (EST) Received: by anchovy.zoic.org (Postfix, from userid 1000) id B0AB670D7C7; Tue, 31 May 2005 13:01:46 +1000 (EST) Date: Tue, 31 May 2005 13:01:46 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Message-ID: <20050531030146.GD26956@zoic.org> Mail-Followup-To: ipv6@ietf.org, James Kempf References: <200505261708.j4QH8dQN012721@rotala.raleigh.ibm.com> <09e701c5621b$79f42690$016115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09e701c5621b$79f42690$016115ac@dcml.docomolabsusa.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ X-Scanned-By: AMaViS-ng at borg.st.net.au X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: James Kempf Subject: Re: Last Call: 'Optimistic Duplicate Address Detection for IPv6' toProposed 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 James, sorry it's taken me a while to get back to you on this. On 2005-05-26, James Kempf wrote: > > In this case, the ability to use "Optimistic" greatly reduces handover > latency, and there doesn't seem to be an issue with routing through the > router because the RA provides the link address. > > Do you see any issues with this that I might have missed? Nope, that's pretty much exactly the case that OptiDAD was designed for. > > Likewise, an Optimistic node can still inject IP packets into the > > Internet that will in effect be "spoofed" packets appearing to come > > from the legitimate node. In some cases, those packets may lead to > > errors or other operational problems, though one would expect that > > upper layer protocols would generally treat such packets robustly, > > in the same way they must treat old and other duplicate packets. > > It is true that an Optimistic attacker can do this, but, really, can't any > IPv6 node do it? An attacking node doesn't have to do DAD, it could simply > come on the link and start sending packets to the Internet with whatever > address it wants. It might not get anything back, of course, since any > response will get sent to the legitimate owner of the address. Yeah, there's an assumption that "good" nodes greatly outnumber "evil" nodes, so the potential harm from "good" nodes occasionally spoofing packets is much more than the everpresent potential evil. Optimistic Nodes won't 'steal' traffic ... they don't get into the router's NC, so the router never misdirects traffic to them. They can send out packets from an address being used by an existing node, and (in the case of a MIPv6 Binding Update, for example) this can cause great wads of traffic to arrive at the existing node, but there's pretty good odds that those packets will just get dropped at their destination anyway. And the existing node is obliged to correct the optimistic node's error within 1000ms anyway. This is where the statistical argument comes in. Address collision (very unlikely) multiplied by the probability of an accidentally spoofed packet actually upsetting anything (very unlikely) equals ... -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 31 00:36:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcyU3-0000ZL-NA; Tue, 31 May 2005 00:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcyU1-0000Z3-HR for ipv6@megatron.ietf.org; Tue, 31 May 2005 00:36:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12900 for ; Tue, 31 May 2005 00:36:02 -0400 (EDT) Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcynY-0000v0-7s for ipv6@ietf.org; Tue, 31 May 2005 00:56:17 -0400 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1 #31112) with ESMTP id <01LOWTLTBZUE9AO0GF@vaxh.its.monash.edu.au> for ipv6@ietf.org; Tue, 31 May 2005 14:35:53 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1B4F3AB543; Tue, 31 May 2005 14:35:53 +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 E84734FB07; Tue, 31 May 2005 14:35:52 +1000 (EST) Date: Tue, 31 May 2005 14:35:47 +1000 From: Greg Daley In-reply-to: <000201c564ec$5a3a3230$6cc6dba8@daniel> To: "Soohong Daniel Park@samsung.com" Message-id: <429BE9A3.4010505@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: <000201c564ec$5a3a3230$6cc6dba8@daniel> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Cc: 'James Kempf' , ipv6@ietf.org, 'Brett Pentland' , "'Soliman, Hesham'" , 'Mohamed Khalil' , 'JINMEI Tatuya / ????' Subject: Re: rfc2461bis issue 257 resolved? fast RA issue 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 Daniel, None of the solutions has been accepted yet as a WG item. The DNA goals draft (in RFC-ed queue) covers this issue, and has a goal for fast reception of information (essentially RAs). The RA delay issue is discussed in section 2.1 of 'dna-goals' and is summarized in Goal: G2. The current revision is: draft-ietf-dna-goals-04.txt Solutions documents are now appearing (some which advance the state of the art significantly beyond the original FastRA solution). Peoples' inputs to DNA WG about these solutions are eagerly sought. Greg Soohong Daniel Park@samsung.com wrote: > Just clarifying. > > >>We'll be interested in IPv6 WG members' feedback on the solution >>which is adopted as a DNA WG draft. >> >>So I request that the issue be removed from the 2461bis issue >>tracker list. > > > Greg, are you saying that the FastRA was already accepted > as DNA WG item ? I didn't include this consideration with > my previous response. Just saying FastRA and 2461bis are > not well matched in my opinion...Adopting FastRA as DNA > WG item seems another issue. > > Thanks. > > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, 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 May 31 07:52:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd5IC-0004Te-3v; Tue, 31 May 2005 07:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd5I9-0004TZ-Ut for ipv6@megatron.ietf.org; Tue, 31 May 2005 07:52:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02314 for ; Tue, 31 May 2005 07:52:17 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/BJpAAGqDNslHhaeZad3XmHRnqQbSwhZQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd5bl-0000hJ-NE for ipv6@ietf.org; Tue, 31 May 2005 08:12:34 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Dd5Hu-0006qr-QO; Tue, 31 May 2005 13:52:09 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1Dd5Ht-0001tb-8P; Tue, 31 May 2005 13:52:01 +0200 Message-ID: <429C4FE0.8030301@tm.uka.de> Date: Tue, 31 May 2005 13:52:00 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?JINMEI_Tatuya_/_=3F=3F=3F=3F?= , greg.daley@eng.monash.edu.au References: <429756F3.5040707@tm.uka.de> <4299FDA2.7040601@tm.uka.de> <429A81F6.6090408@eng.monash.edu.au> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -18.8 (------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: Mark Doll , TM-RO2 , Roland Bless , IPv6 Subject: Re: Comment on RFCs 2461bis and 2462bis 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 last thing below... > 2461bis-03 reads: > > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when > many hosts start up on a link at the same time, such as might happen > after recovery from a power failure. If a host has already > performed a random delay since the interface became (re)enabled > (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no > need to delay again before sending the first Router Solicitation > message. (Notice the last sentence) > > and rfc2462bis-08 reads: > > If the Neighbor Solicitation is going to be the first message to be > sent from an interface after interface (re)initialization, the node > SHOULD delay joining the solicited-node multicast address by a random > delay [...] (Notice the "If" condition) > > I believe it is pretty clear that these specifications indicate a > single delay only applicable to either D1 or D2. I didn't doubt that the single delay is correctly specified as such. This is very clear in my opinion. What I was wondering was that, although D[123] are conceptually the same, only D1 gets eliminated in the special case that the host is mobile. Since the WG consensus is not to eliminate D2 and D3 for MNs in RFC246[12]bis, eliminating D1 is superfluous as far as I see. After all, the MNs will end up waiting anyway, namely for D2 or D3. At least in the very, very likely case that they autoconfigure a new IPv6 address after the handover. I think Greg's opinion on this is different. I'm not sure why, though. Ok, so let's settle this issue. Thanks for discussing this. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ JINMEI Tatuya wrote: >>>>>> On Mon, 30 May 2005 13:01:10 +1000, Greg Daley >>>>>> said: > > > >>> Well, here is the scenario I am thinking of: A MN uses >>> unsolicited RAs---neither RSs, nor link-layer triggers---to >>> detect IP-attachment changes. Assuming that routers send their >>> RAs every 50ms on average, which is what RFC 3775 allows them to >>> do, this movement-detection strategy works better than sending >>> RSs. The reason is the random delay for solicited RAs, as you >>> say. Even if the MN would use L2 triggers, it would still have >>> to send an RS and await the random RA-delay in order to find out >>> the new prefix(es). >>> >>> So, RFC 3775's frequent (unsolicited) RAs can be leveraged for >>> movement detection quite nicely. But when it comes to >>> configuring the new address, the MN ends up having to wait for D2 >>> or D3 to send the MLD Report. In other words, eliminating D1 >>> turns out to be useless as long as D2 and D3 are still there. > > > >> The main issue here is that there's an unsolicited RA which many >> people may have received, and no indication of movement from L2, so >> the host is unsure why the change occurred. > > > >> In this case, the host should be conservative in what it sends, and >> make use of a delay in order to prevent DAD contention with other >> unknown configuring hosts. > > > > Thanks, this is exactly what I'm going to explain in this message. I > believe I don't need to say anything more for rejecting the > elimination of D3 *in rfc2462bis*. (Again, this does not preclude > future efforts for optimizing the delay further) > > >> The delay D1 is not applicable here (no L2 hint), but a single >> delay for DAD NS and MLD may be applicable as you say. > > > >> I guessed that the new text in 2462bis covers this nicely, though. > > > > I agree. If the point is to introduce a single delay for D1 and D2 > (note that we cannot make the elimination of D3 for a different > reason), we should be already done. > > 2461bis-03 reads: > > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when > many hosts start up on a link at the same time, such as might happen > after recovery from a power failure. If a host has already > performed a random delay since the interface became (re)enabled > (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no > need to delay again before sending the first Router Solicitation > message. (Notice the last sentence) > > and rfc2462bis-08 reads: > > If the Neighbor Solicitation is going to be the first message to be > sent from an interface after interface (re)initialization, the node > SHOULD delay joining the solicited-node multicast address by a random > delay [...] (Notice the "If" condition) > > I believe it is pretty clear that these specifications indicate a > single delay only applicable to either D1 or D2. > > So, are we done (within the scope of 2461bis/2462bis)? > > 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 May 31 17:04:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDus-0008C9-QR; Tue, 31 May 2005 17:04:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdDuq-0008C3-93 for ipv6@megatron.ietf.org; Tue, 31 May 2005 17:04:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00443 for ; Tue, 31 May 2005 17:04:46 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdEEW-0006Fl-2i for ipv6@ietf.org; Tue, 31 May 2005 17:25:09 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 14:04:36 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 14:04:36 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 14:04:36 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 14:04:36 -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: Tue, 31 May 2005 14:04:35 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC111C2B892@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt thread-index: AcVh1wI+XsZk7d7gS7uJe41Q3MCdqgES9J1Q From: "Dave Thaler" To: "IPv6 WG" X-OriginalArrivalTime: 31 May 2005 21:04:36.0174 (UTC) FILETIME=[59D256E0:01C56624] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.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 Tim Chown writes: > On Tue, May 24, 2005 at 10:44:37AM -0400, Bound, Jim wrote: > > > > My response below. Thus I cannot support this going to the IESG without > > further discussion as my input. I also support Margaret's request for > > this to be checked by RTSP persons, and I realize Dave T. clearly has > > this expertise but it is a good logic check. Unless we want to remove > > RSTP. I think we should include RSTP but it needs more review. >=20 > This seems sensible. RSTP folks are reviewing this, and based on their recommendations we will fix or remove the RSTP use. (As the editor, I am okay with either direction.) At last IETF, I got agreement from Paul Congdon (vice-chair of 802.1D, which owns the RSTP protocol) and Bernard Aboba (who's the IEEE liaison on the IAB, and the person who originally reviewed the old draft and said it should use RSTP now) to review the use of RSTP in draft -02 once it came out. =20 Now that draft -02 is out, I have again asked for their reviews, and I will wait for their recommendation before updating. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue May 31 18:18:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdF4K-0004XZ-CH; Tue, 31 May 2005 18:18:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdF4I-0004XP-6P for ipv6@megatron.ietf.org; Tue, 31 May 2005 18:18:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05158 for ; Tue, 31 May 2005 18:18:35 -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.33) id 1DdFNy-0001Pu-3D for ipv6@ietf.org; Tue, 31 May 2005 18:38:59 -0400 Message-ID: <000e01c5662e$d7733e70$5a6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Soohong Daniel Park@samsung.com" , References: <000201c564ec$5a3a3230$6cc6dba8@daniel> Date: Mon, 30 May 2005 11:00:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "'Soliman, Hesham'" , 'Brett Pentland' , ipv6@ietf.org, 'Mohamed Khalil' , 'JINMEI Tatuya / ????' Subject: Re: rfc2461bis issue 257 resolved? fast RA issue 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 draft-pettland already contains something to speed up the RA. It doesn't have to be a separate WG item. jak ----- Original Message ----- From: "Soohong Daniel Park@samsung.com" To: Cc: "'Soliman, Hesham'" ; ; "'JINMEI Tatuya / ????'" ; "'James Kempf'" ; "'Brett Pentland'" ; "'Mohamed Khalil'" Sent: Monday, May 30, 2005 12:51 AM Subject: RE: rfc2461bis issue 257 resolved? fast RA issue > Just clarifying. > > > We'll be interested in IPv6 WG members' feedback on the solution > > which is adopted as a DNA WG draft. > > > > So I request that the issue be removed from the 2461bis issue > > tracker list. > > Greg, are you saying that the FastRA was already accepted > as DNA WG item ? I didn't include this consideration with > my previous response. Just saying FastRA and 2461bis are > not well matched in my opinion...Adopting FastRA as DNA > WG item seems another issue. > > Thanks. > > --------------------------------------------- > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics. > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------