From ipv6-bounces@ietf.org Tue May 31 19:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdGYI-0002pU-H4; Tue, 31 May 2005 19:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdGYG-0002pO-20 for ipv6@megatron.ietf.org; Tue, 31 May 2005 19:53: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 TAA11041 for ; Tue, 31 May 2005 19:53:36 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdGrs-0005tN-Ak for ipv6@ietf.org; Tue, 31 May 2005 20:14:02 -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 <0IHD00I2MP0VSK@mailout1.samsung.com> for ipv6@ietf.org; Wed, 01 Jun 2005 08:53:19 +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 <0IHD00MCTP0UVY@mmp1.samsung.com> for ipv6@ietf.org; Wed, 01 Jun 2005 08:53:19 +0900 (KST) Date: Wed, 01 Jun 2005 08:53:17 +0900 From: "Soohong Daniel Park@samsung.com" In-reply-to: <000e01c5662e$d7733e70$5a6015ac@dcml.docomolabsusa.com> To: "'James Kempf'" , greg.daley@eng.monash.edu.au Message-id: <00ec01c5663b$ead35830$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: 4d87d2aa806f79fed918a62e834505ca 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 for folks information. > draft-pettland already contains something to > speed up the RA. It doesn't have to be a > separate WG item. Agreed. http://www.watersprings.org/pub/id/draft-pentland-dna-protocol-00.txt 3.3 Fast Router Advertisment According to RFC 2461 a solicited Router Advertisement should have a random delay between 0 and 500 milliseconds, to avoid the advertisements from all the routers colliding on the link causing congestion and higher probability of packet loss. In addition, RFC 2461 suggests that the RAs be multicast, and multicast RAs are rate limited to one message every 3 seconds. This implies that the response to a RS might be delayed up to 3.5 seconds. DNAv6 avoids this delay by using a different mechanism to ensure that two routers will not respond at exactly the same time while allowing one of the routers on the link to respond immediately. Since the hosts might be likely to use the first responding router as the first choice from their default router list, the mechanism also ensures that the same router doesn't respond first to the RSs from different hosts. The mechanism is based on the routers on the link determining (from the same RAs that are used in section Section 3.1 to determine all the prefixes assigned to the link), the link-local addresses of all the other routers on the link. With this loosely consistent list, each router can independently compute some function of the (link- local) source address of the RS and each of the routers' link-local addresses. The results of that function are then compared to create a ranking, and the ranking determines the delay each router will use when responding to the RS. The router which is ranked as #0 will respond with a zero delay. If the routers become out-of-sync with respect to their learned router lists, two or more routers may respond with the same delay, but over time the routers will converge on their lists of learned routers on the link. --------------------------------------------- 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 Jun 01 06:59:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdQx1-0000ix-Dw; Wed, 01 Jun 2005 06:59:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdQwz-0000io-Ge; Wed, 01 Jun 2005 06:59: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 GAA03591; Wed, 1 Jun 2005 06:59:50 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdRGm-0003uk-Jc; Wed, 01 Jun 2005 07:20:22 -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 j51AxemJ001317 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 1 Jun 2005 12:59:40 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <936A4045C332714F975800409DE0924054176C@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924054176C@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: <7CC46CE2-38E6-4D17-AC92-6186ED55DE88@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 1 Jun 2005 12:59:33 +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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, IETF IPv6 Mailing List Subject: Proposal for m/o bits, was: 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 22:23, Bound, Jim wrote: > 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. > Do we need both bits but we need one for them for sure. What I sense is that people who are interested in using DHCPv6 want to be able to do DHCPv6 even if the routers don't explicitly say it's ok, while others want to make sure the routers can instruct hosts to NOT do DHCPv6. So what about this: M = 0, O = 0: hosts use their default mechanisms. There is no assumption that a host will use DHCPv6, but there is also no assumption that a host will NOT use DHCPv6. M = 1, O = 0: hosts use full stateful DCHPv6 to obtain addresses and/ or other information to the degree that they can. Obviously there are hosts that don't implement DHCPv6 or don't implement address assignment, but the assumption is that DHCP will be used when possible. M = 0, O = 1: hosts use some kind of stateless DHCPv6 to obtain other information. DHCPv6 servers won't offer address information, and hosts don't ask for it, and reject it when they get it anyway. The exact DHCPv6 variation that should be used in this case will be determined by the dhc wg asap, the idea being that in this case the interaction and implementations are as light weight as possible. M = 1, O = 1: hosts do NOT use DHCPv6, overriding any default behavior. I think this accommodates all needs, with only the slight inconvenience that the M = 1, O = 1 behavior is the exact opposite from what we are supposed to have now. I would be happy to receive yes/no comments (or more) in private email and summarize those to the lists if people have an opinion but don't want to join the discussion and not waste bandwidth with monosyllabic posts. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 07:31:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdRRe-0000jO-Kr; Wed, 01 Jun 2005 07:31:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdRRc-0000iw-Ii; Wed, 01 Jun 2005 07:31: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 HAA06758; Wed, 1 Jun 2005 07:31: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 1DdRlQ-0005bR-4V; Wed, 01 Jun 2005 07:52:01 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2005 07:31:22 -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 j51BVJ4u001324; Wed, 1 Jun 2005 07:31:20 -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, 1 Jun 2005 07:31:19 -0400 Received: from 10.86.240.202 ([10.86.240.202]) 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, 1 Jun 2005 11:31:18 +0000 Received: from localhost.localdomain by email.cisco.com; 01 Jun 2005 07:31:49 -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: Wed, 01 Jun 2005 07:31:49 -0400 Message-Id: <1117625509.9005.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 01 Jun 2005 11:31:19.0306 (UTC) FILETIME=[6E1A8EA0:01C5669D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 We need to agree on requirements before we try to engineer solutions. Here is what I've heard as requirements: 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. Comments? - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 08:06:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdRzg-0000be-TR; Wed, 01 Jun 2005 08:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdRze-0000Zt-ME; Wed, 01 Jun 2005 08:06: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 IAA10343; Wed, 1 Jun 2005 08:06:39 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdSJT-0007kM-CP; Wed, 01 Jun 2005 08:27:11 -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 j51C4fmJ002302 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 1 Jun 2005 14:04:43 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1117625509.9005.58.camel@localhost.localdomain> References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> <1117625509.9005.58.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84B63699-D7CD-4A6D-9C0A-5A933F0AC013@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 1 Jun 2005 14:04:35 +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: 79899194edc4f33a41f49410777972f8 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 1-jun-2005, at 13:31, Ralph Droms wrote: > We need to agree on requirements before we try to engineer solutions. :-) > Here is what I've heard as requirements: > 1) Ability to indicate to a host "DHCP is not available on this link", > 2) Ability for a host to get all desired and available DHCP > configuration with a single DHCP message exchange > Comments? 3 Ability to limit DHCP use to other configuration only And, apparently: 4 Ability to do DHCP without having to configure routers -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 08:26:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSIm-0004cI-54; Wed, 01 Jun 2005 08:26:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSIj-0004cA-Qf; Wed, 01 Jun 2005 08:26: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 IAA11479; Wed, 1 Jun 2005 08:26:22 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdScW-0000Ft-Pf; Wed, 01 Jun 2005 08:46:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2005 08:26:14 -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 j51CPf5G013718; Wed, 1 Jun 2005 08:26:11 -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); Wed, 1 Jun 2005 08:26: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: Wed, 1 Jun 2005 08:25:59 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB213391C0@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVmop5DUMI5JXTIQr2N1fdIsvN+HgAAZAQA From: "Bernie Volz \(volz\)" To: "Iljitsch van Beijnum" , "Ralph Droms \(rdroms\)" X-OriginalArrivalTime: 01 Jun 2005 12:26:00.0403 (UTC) FILETIME=[11CA3A30:01C566A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 > 4 Ability to do DHCP without having to configure routers I'm not sure I'd draw that conclusion. I think the point was that hosts *MAY* ignore any RA "hints" and do what they are manually configured to do - whether that is to run DHCPv6 always or never. But this is not something that needs to be explicitly stated - it is implicit in the current definition of the bits because they are SHOULD, not MUST. > 3 Ability to limit DHCP use to other configuration only This can be accomplished in two ways - have clients only send Information-Request OR allow them to send Solicits and "fix" DHCPv6 to allow only other configuration parameters to be communicated in an Advertise. Of course, the latter has come interoperatability issues with existing implementations. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Iljitsch van Beijnum > Sent: Wednesday, June 01, 2005 8:05 AM > To: Ralph Droms (rdroms) > Cc: dhcwg@ietf.org; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit >=20 > On 1-jun-2005, at 13:31, Ralph Droms wrote: >=20 > > We need to agree on requirements before we try to engineer=20 > solutions. >=20 > :-) >=20 > > Here is what I've heard as requirements: >=20 > > 1) Ability to indicate to a host "DHCP is not available on=20 > this link", >=20 > > 2) Ability for a host to get all desired and available DHCP > > configuration with a single DHCP message exchange >=20 > > Comments? >=20 > 3 Ability to limit DHCP use to other configuration only >=20 > And, apparently: >=20 > 4 Ability to do DHCP without having to configure routers >=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 Jun 01 08:30:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSML-0005AA-Ai; Wed, 01 Jun 2005 08:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSMJ-00059y-Py; Wed, 01 Jun 2005 08:30: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 IAA11758; Wed, 1 Jun 2005 08:30:04 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdSg7-0000Rh-9d; Wed, 01 Jun 2005 08:50:37 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j51CTjh13145; Wed, 1 Jun 2005 15:29:45 +0300 Date: Wed, 1 Jun 2005 15:29:45 +0300 (EEST) From: Pekka Savola To: Ralph Droms In-Reply-To: <1117625509.9005.58.camel@localhost.localdomain> Message-ID: References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> <1117625509.9005.58.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Wed, 1 Jun 2005, Ralph Droms wrote: > 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 It would be even better to keep backward compatibility, i.e., not require extensions to ICB-only DHCP servers to support Solicits. Let's face it, those extensions always take time to specify, code and deploy, the admins will have to wait for new versions, etc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 08:36:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSSD-0006v0-7a; Wed, 01 Jun 2005 08:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSSB-0006uP-IC; Wed, 01 Jun 2005 08:36: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 IAA12314; Wed, 1 Jun 2005 08:36:08 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdSm0-0000mN-4o; Wed, 01 Jun 2005 08:56:40 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2005 08:36:00 -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 j51CZolA022990; Wed, 1 Jun 2005 08:35:57 -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, 1 Jun 2005 08:35:53 -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 ; Wed, 1 Jun 2005 12:35:52 +0000 Received: from localhost.localdomain by email.cisco.com; 01 Jun 2005 08:36:23 -0400 From: Ralph Droms To: Pekka Savola In-Reply-To: References: <5D200A6BB92BB54F8E2FED8E4A28D7630514F071@RRMAILER.rr.com> <1117625509.9005.58.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2005 08:36:23 -0400 Message-Id: <1117629383.11049.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 01 Jun 2005 12:35:53.0147 (UTC) FILETIME=[7317C8B0:01C566A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Pekka - In theory, I agree. In practice, it's early enough to make a change before we have extensive deployments and the lack of backward compatibility only affects a few deployments, where a host requesting HCB would be satisfied with and ICB response. So, I don't think backward compatibility is as important as improving the protocol. - Ralph On Wed, 2005-06-01 at 15:29 +0300, Pekka Savola wrote: > On Wed, 1 Jun 2005, Ralph Droms wrote: > > 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 > > It would be even better to keep backward compatibility, i.e., not > require extensions to ICB-only DHCP servers to support Solicits. > Let's face it, those extensions always take time to specify, code and > deploy, the admins will have to wait for new versions, etc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 08:43:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSZd-0000sg-Ao; Wed, 01 Jun 2005 08:43:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdSZa-0000s9-I6; Wed, 01 Jun 2005 08:43: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 IAA12903; Wed, 1 Jun 2005 08:43:46 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdStN-00018d-Mb; Wed, 01 Jun 2005 09:04:19 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id F1438123; Wed, 1 Jun 2005 08:43:35 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 08:43: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: Wed, 1 Jun 2005 08:43:33 -0400 Message-ID: <936A4045C332714F975800409DE09240541B81@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVmnxYIi+s7l0UdTdiYEVnJ4816cQAB/D8Q From: "Bound, Jim" To: "Ralph Droms" , , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 01 Jun 2005 12:43:35.0879 (UTC) FILETIME=[86E71570:01C566A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 =20 > We need to agree on requirements before we try to engineer solutions. > Here is what I've heard as requirements: >=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)=20 > and receives > HCB and/or ICB replies > - if a host wants ICB, it sends an ICB request=20 > (Information-request)=20 > and receives ICB replies >=20 I agree. > 1 is a requirement in scenarios with limited resources (e.g.,=20 > wireless),=20 add e.g. wireless, admin does not want stateful) This is important. Many here beleive that stateful should never be used other than for configuration. =20 > where polling for DHCP is unacceptable. =20 2 is a requirement to avoid > timeout delays or other complexity in getting ICB reply when=20 > host would > prefer HCB reply. Problem is what controls if addresses are permitted to be requested? =20 I liked my layout of the problems better :--) thanks /jim >=20 > Comments? >=20 > - Ralph >=20 >=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 Wed Jun 01 09:37:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTPE-0005Ix-AS; Wed, 01 Jun 2005 09:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdTPC-0005Ir-OH for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 09:37: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 JAA16377 for ; Wed, 1 Jun 2005 09:37:08 -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 1DdTj1-0003pv-FB for ipv6@ietf.org; Wed, 01 Jun 2005 09:57:40 -0400 Received: from ([128.244.124.185]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.12375297; Wed, 01 Jun 2005 09:36:40 -0400 Mime-Version: 1.0 (Apple Message framework v622) To: IPv6 WG Message-Id: <717230f87accc38a4d6a6c37b6b04b37@innovationslab.net> From: Brian Haberman Date: Wed, 1 Jun 2005 09:36:42 -0400 X-Mailer: Apple Mail (2.622) X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Way Forward: draft-ietf-ipv6-ra-mo-flags X-BeenThere: ipv6@ietf.org 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="===============0257382414==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0257382414== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--260634142; protocol="application/pkcs7-signature" --Apple-Mail-2--260634142 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit All, The on-going discussion on the M/O flags and DHCPv6 has been quite useful. The IPv6 chairs are glad that collaboration is occurring on potentially simplifying the operational behavior of DHCPv6. The messages have indicated that the WG sees consensus on changing the contents of the M/O flags draft. Namely, that the M/O flags are hints to the existence of stateful and stateless DHCPv6 servers respectively. Additionally, the draft should refrain from defining operational policy since that area is better understood by the implementers and the users of the systems. We strongly encourage everyone to continue working with the DHC WG to come to a resolution on the DHCPv6 behavior while this draft is revised and continues on with advancement. Regards, Brian & Bob IPv6 WG co-chairs --Apple-Mail-2--260634142 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNjAxMTMzNjQzWjAjBgkqhkiG9w0B CQQxFgQUAetbYj8RZZtBG3l/cqfbXRvxbpEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwz21DB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMM9tQwDQYJKoZIhvcNAQEB BQAEggEAu5k3U5wywxO0G3/Vcz8FgPpN0DkF41ozA5jlcqZoejxwoke9FPz5lc++qdgoZ25hv1So fCxnIKczSkAUfH6QPoDGWVA68nDb1YhR5MGheyCKqVPcclRUp0o1f72RM43VmXWSg+OE5AR0kFvY 6ZdVDh9T3nPGfB+JSc71yegAHaEDuj7cXRwbA8M9Wl2fo98scSFLwkizH1M3Sgj9XJWoyXgmM17N 3wW61exUS7k9tvzaX3OD4giSWYIFzEs9/8ePk8kGmhVvZ0oCns1MBHAAqh112V4LnrxgMaYGTy5S N520Yk8E9+uaiB120Uh7utUINQD5USGKCBFk7GVNQiWYjAAAAAAAAA== --Apple-Mail-2--260634142-- --===============0257382414== 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 -------------------------------------------------------------------- --===============0257382414==-- From ipv6-bounces@ietf.org Wed Jun 01 10:50:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUYQ-0008U4-SQ; Wed, 01 Jun 2005 10:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUYO-0008Qn-Qr; Wed, 01 Jun 2005 10:50: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 KAA23186; Wed, 1 Jun 2005 10:50:42 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUsD-0007hi-Rb; Wed, 01 Jun 2005 11:11:15 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 15:50:32 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Jun 2005 15:50:32 +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: Wed, 1 Jun 2005 15:50:32 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A700F3C8609@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVmprgahzqqw1WHTvWcw4rYFFxGHAAEgGwQ To: , X-OriginalArrivalTime: 01 Jun 2005 14:50:32.0447 (UTC) FILETIME=[42BB20F0:01C566B9] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 dhcwg-bounces@ietf.org wrote: > On Wed, 1 Jun 2005, Ralph Droms wrote: >> 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 >=20 > It would be even better to keep backward compatibility, i.e., not > require extensions to ICB-only DHCP servers to support Solicits. > Let's face it, those extensions always take time to specify, code and > deploy, the admins will have to wait for new versions, etc. What admins? Several posts in this thread indicate that there is little if any production deployment of DHCPv6 right now. -- Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 11:49:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVSq-0002ir-Kw; Wed, 01 Jun 2005 11:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVSo-0002cE-Hl for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 11:49: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 LAA28057 for ; Wed, 1 Jun 2005 11:48:59 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdVme-0002JD-80 for ipv6@ietf.org; Wed, 01 Jun 2005 12:09:33 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j51Fmt0T013188 for ; Wed, 1 Jun 2005 09:48:55 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHE00501X4PBM@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for ipv6@ietf.org; Wed, 01 Jun 2005 11:48:55 -0400 (EDT) Received: from 129.148.174.103 (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IHE00BC0X9JOA@bur-mail2.east.sun.com>; Wed, 01 Jun 2005 11:48:55 -0400 (EDT) Date: Wed, 01 Jun 2005 11:48:55 -0400 From: Sebastien Roy In-reply-to: To: "Soliman, Hesham" Message-id: <1117640935.7273.11.camel@strat> Organization: Solaris Network & Security Technologies, Sun Microsystems MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT 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, 2005-05-24 at 10:04, Soliman, Hesham wrote: > I think this draft is now ready for the IESG. I have one issue with APPENDIX A. The direct mention of the on-link assumption was removed from the appendix (from the second bullet item 1), but it is still implied by the text that remains. The text is: 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. Why would a multihomed host ever attempt to perform any address resolution on any interface unless it assumed that the destination was on-link on one of those interfaces? It should not make this assumption at all. While the text is accurate in stating that this involves significant complexity, it should not suggest that doing on-link address resolution for a node to which it has no route is a "possible approach". If you're multihomed and you have no route to a destination, then send back an ICMP destination unreachable. It should be as simple as that. If the destination is a link-local address, then that's a different matter entirely. In that case, it's a matter of scope ambiguity. The text may have been addressing this particular case, but it's not clear to me. -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 12:07:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVkc-0001p1-Fd; Wed, 01 Jun 2005 12:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVka-0001ot-Hn; Wed, 01 Jun 2005 12:07: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 MAA29441; Wed, 1 Jun 2005 12:07:21 -0400 (EDT) Received: from mignon.ki.iif.hu ([193.6.222.240] helo=mail.ki.iif.hu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdW4Q-0003G8-Gc; Wed, 01 Jun 2005 12:27:55 -0400 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 95DB75586; Wed, 1 Jun 2005 18:07:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 93B315583; Wed, 1 Jun 2005 18:07:12 +0200 (CEST) Date: Wed, 1 Jun 2005 18:07:12 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: matthew.ford@bt.com In-Reply-To: <0AAF93247C75E3408638B965DEE11A700F3C8609@i2km41-ukdy.domain1.systemhost.net> Message-ID: <20050601180358.J96010@mignon.ki.iif.hu> References: <0AAF93247C75E3408638B965DEE11A700F3C8609@i2km41-ukdy.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dhcwg@ietf.org, ipv6@ietf.org, pekkas@netcore.fi, rdroms@cisco.com 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, 1 Jun 2005 matthew.ford@bt.com wrote: > dhcwg-bounces@ietf.org wrote: >> On Wed, 1 Jun 2005, Ralph Droms wrote: >>> 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 >> >> It would be even better to keep backward compatibility, i.e., not >> require extensions to ICB-only DHCP servers to support Solicits. >> Let's face it, those extensions always take time to specify, code and >> deploy, the admins will have to wait for new versions, etc. > > What admins? Several posts in this thread indicate that there is little > if any production deployment of DHCPv6 right now. > This not true. There are several systems are using DHCPv6 to distribute DNS server information via IPv6. We also use this capability for more than one year in production. Keeping combatibility to some extent, is always a golden rule Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > -- Mat > > -------------------------------------------------------------------- > 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 Jun 01 12:16:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVtK-0000Td-AL; Wed, 01 Jun 2005 12:16:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVtI-0000NJ-3c for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 12:16: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 MAA00312 for ; Wed, 1 Jun 2005 12:16:21 -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 1DdWD8-0003gD-7U for ipv6@ietf.org; Wed, 01 Jun 2005 12:36:55 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Jun 2005 12:16:11 -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, 1 Jun 2005 12:16:10 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVmwWuTfT6iODY+Rr23WwGa9fT0KwAAyGVw From: "Soliman, Hesham" To: "Sebastien Roy" X-OriginalArrivalTime: 01 Jun 2005 16:16:11.0958 (UTC) FILETIME=[3A1E4560:01C566C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 > I have one issue with APPENDIX A. The direct mention of the on-link > assumption was removed from the appendix (from the second bullet item > 1), but it is still implied by the text that remains. The text is: >=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 > Why would a multihomed host ever attempt to perform any address > resolution on any interface unless it assumed that the=20 > destination was > on-link on one of those interfaces? It should not make this=20 > assumption > at all. While the text is accurate in stating that this involves > significant complexity, it should not suggest that doing=20 > on-link address > resolution for a node to which it has no route is a "possible > approach". If you're multihomed and you have no route to a=20 > destination, > then send back an ICMP destination unreachable. It should=20 > be as simple > as that. =3D> How do you know if you have no route to the destination? Could it not be on one of the links? The difference is that this case does not _assume_ that the destination is on-link, which was there before.=20 In any case, this issue was discussed with Jinmei last week and=20 here is the suggested text that we agreed on. Please let me know if you have a comment: >> 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. 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 Jun 01 12:24:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdW1B-0004DP-2J; Wed, 01 Jun 2005 12:24:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdW18-0004DH-H3; Wed, 01 Jun 2005 12:24: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 MAA01562; Wed, 1 Jun 2005 12:24:27 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdWKz-0004A1-Hf; Wed, 01 Jun 2005 12:45:01 -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 j51GONmJ006591 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 1 Jun 2005 18:24:23 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8E296595B6471A4689555D5D725EBB213391C0@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB213391C0@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: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Wed, 1 Jun 2005 18:24:17 +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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 1-jun-2005, at 14:25, Bernie Volz ((volz)) wrote: >> 4 Ability to do DHCP without having to configure routers > I'm not sure I'd draw that conclusion. I think the point was that > hosts > *MAY* ignore any RA "hints" and do what they are manually > configured to > do Treating RA information that DHCPv6 servers aren't available as a hint and ignoring the hint is an implementation of the ability to do DHCP without having to configure routers. > - whether that is to run DHCPv6 always or never. But this is not > something that needs to be explicitly stated - it is implicit in the > current definition of the bits because they are SHOULD, not MUST. Doing DHCPv6 when there is positive knowledge that there is no DHCPv6 server is suboptimal, and may have nasty security implications. (Especially when we get SEND for secure RAs.) It is also very wasteful in bandwidth constrained environments. It is of course possible to implement all kinds of heuristics to determine where and when we can do DHCPv6 when the hints say "don't do it", but I think upgrading from "yes / no" to "yes / default behavior / no" makes more sense. >> 3 Ability to limit DHCP use to other configuration only > This can be accomplished in two ways - have clients only send > Information-Request OR allow them to send Solicits and "fix" DHCPv6 to > allow only other configuration parameters to be communicated in an > Advertise. Of course, the latter has come interoperatability issues > with > existing implementations. Right. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 12:58:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdWXj-0003xi-AF; Wed, 01 Jun 2005 12:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdWXh-0003wK-Pc for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 12:58:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04416 for ; Wed, 1 Jun 2005 12:58:06 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdWrY-0005st-4w for ipv6@ietf.org; Wed, 01 Jun 2005 13:18:41 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j51Gvn27006000 for ; Wed, 1 Jun 2005 10:58:07 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHF00B010FF93@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for ipv6@ietf.org; Wed, 01 Jun 2005 12:57:50 -0400 (EDT) Received: from 129.148.174.103 (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IHF00BM20GDOA@bur-mail2.east.sun.com>; Wed, 01 Jun 2005 12:57:49 -0400 (EDT) Date: Wed, 01 Jun 2005 12:57:48 -0400 From: Sebastien Roy In-reply-to: To: "Soliman, Hesham" Message-id: <1117645068.7273.19.camel@strat> Organization: Solaris Network & Security Technologies, Sun Microsystems MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT 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, 2005-06-01 at 12:16, Soliman, Hesham wrote: > => How do you know if you have no route to the destination? You consult your forwarding table. > Could it not be on one of the links? It could be if you have a forwarding table entry that points to one or more of your local interfaces. > The difference is that > this case does not _assume_ that the destination is on-link, which > was there before. I does assume that that the destination is on-link. In outbound packet processing, you don't attempt to do link-layer address resolution until you've done the forwarding table lookup and done on-link determination. > > In any case, this issue was discussed with Jinmei last week and > here is the suggested text that we agreed on. Please let me know > if you have a comment: > > >> 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. The same argument does not apply to single homed nodes. The point of removing the on-link assumption was to make sure the node does _not_ do address resolution in the absence of a route to the destination. Are you saying that it's ok to do that if you have more than one network interface? That's how I read this text. -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 13:16:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdWpV-0003Wl-FY; Wed, 01 Jun 2005 13:16:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdWpT-0003WD-0D; Wed, 01 Jun 2005 13:16: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 NAA06172; Wed, 1 Jun 2005 13:16:27 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdX9J-0006pf-5s; Wed, 01 Jun 2005 13:37:02 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 7054920000D5; Wed, 1 Jun 2005 13:16:16 -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, 1 Jun 2005 13:15: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: Wed, 1 Jun 2005 13:15:42 -0400 Message-ID: <936A4045C332714F975800409DE09240541D08@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVmxsvfZRPOtg/zR9uPrdzsmwIe5QABUMsA From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Bernie Volz ((volz))" X-OriginalArrivalTime: 01 Jun 2005 17:15:44.0245 (UTC) FILETIME=[8B5E0250:01C566CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 > Treating RA information that DHCPv6 servers aren't available as a =20 > hint and ignoring the hint is an implementation of the ability to do =20 > DHCP without having to configure routers. I agree and I think most agree that the router RA determines if dhc is to be used at all. Thus that purpose of the "m" bit is valid and useful. Thus I support that if the router does not set the m bit that the client MUST not use dhc. > > This can be accomplished in two ways - have clients only send > > Information-Request OR allow them to send Solicits and=20 > "fix" DHCPv6 to > > allow only other configuration parameters to be communicated in an > > Advertise. Of course, the latter has come=20 > interoperatability issues =20 > > with > > existing implementations. >=20 > Right. If the M bit is set then it is up to the dhc client per the dhc server what the client is permitted to do as dhc client. This implies to a network site setting the m bit means giving all dhc control for policy to the dhc server as to what the client can do or not do. Which to me makes sense. This means we don't need the o bit is my view. Now as that affects ND and Addrconf and all I care about for this discussion, not dhc for a moment, here is my suggestion, if we did reaach consensus we only need the m bit. Deprecate the o bit in some proper IETF way, and leave that bit position for 1 year alone and not resusable for 1 year. This permits ND and Addrconf code bases to update and simply delete the code base for the o bit. How we do that in a "proper" way is important. Then that bit would be reusable for the IETF within ND after 1 year. My first concern is to reduce the pain to ND and addrconf implementations which is widely deployed. Then dhc can work on the means to set the policy which is dhc and I think backwards compatibility will not be painful, if we do this very quickly. Note very quickly like in 3 months. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 13:58:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXUO-0007lW-QF; Wed, 01 Jun 2005 13:58:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXUM-0007lR-SS for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 13:58: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 NAA10301 for ; Wed, 1 Jun 2005 13:58: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 1DdXoD-0000mX-Mr for ipv6@ietf.org; Wed, 01 Jun 2005 14:19:19 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:98de:b191:9169:e7c9]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B2C2415225; Thu, 2 Jun 2005 03:01:33 +0900 (JST) Date: Thu, 02 Jun 2005 02:59:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Sebastien Roy In-Reply-To: <1117645068.7273.19.camel@strat> References: <1117645068.7273.19.camel@strat> 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: c1c65599517f9ac32519d043c37c5336 Cc: "Soliman, Hesham" , 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, 01 Jun 2005 12:57:48 -0400, >>>>> Sebastien Roy said: >> In any case, this issue was discussed with Jinmei last week and >> here is the suggested text that we agreed on. Please let me know >> if you have a comment: >> >> >> 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. > The same argument does not apply to single homed nodes. The point of > removing the on-link assumption was to make sure the node does _not_ do > address resolution in the absence of a route to the destination. Are > you saying that it's ok to do that if you have more than one network > interface? That's how I read this text. If you've not read the discussion last week, please check the following links: http://www1.ietf.org/mail-archive/web/ipv6/current/msg05047.html http://www1.ietf.org/mail-archive/web/ipv6/current/msg05050.html http://www1.ietf.org/mail-archive/web/ipv6/current/msg05053.html http://www1.ietf.org/mail-archive/web/ipv6/current/msg05057.html http://www1.ietf.org/mail-archive/web/ipv6/current/msg05058.html In summary, I believe I stand at the same position as yours. My understanding of the current wording in the 03 draft is that it strangely talks about a "multihome version of on-link assumption". While I was not convinced with Hesham's response that "this is actually not the on-link assumption since this is just 'attempt', not a 'requirement'", I suggested the above text in case we really still want to emphasize the complexity specific to the multihomed case. As I stated in msg05058.html, my primary preference is to remove this part altogether with the removal of the on-link assumption. 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 Jun 01 14:13:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXgo-0005jD-9m; Wed, 01 Jun 2005 14:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXgl-0005i2-UV for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 14:11: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 OAA11231 for ; Wed, 1 Jun 2005 14:11:32 -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 1DdY0b-0001U1-1T for ipv6@ietf.org; Wed, 01 Jun 2005 14:32:08 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Jun 2005 14:11:24 -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, 1 Jun 2005 14:11:23 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVmyxWf8PoIRRLHQSe+dNbJcEvgqwACQ+wg From: "Soliman, Hesham" To: "Sebastien Roy" X-OriginalArrivalTime: 01 Jun 2005 18:11:24.0128 (UTC) FILETIME=[5217B600:01C566D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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, 2005-06-01 at 12:16, Soliman, Hesham wrote: > > =3D> How do you know if you have no route to the destination? >=20 > You consult your forwarding table. >=20 > > Could it not be on one of the links? >=20 > It could be if you have a forwarding table entry that points=20 > to one or > more of your local interfaces. >=20 > > The difference is that > > this case does not _assume_ that the destination is on-link, which > > was there before.=20 >=20 > I does assume that that the destination is on-link. In=20 > outbound packet > processing, you don't attempt to do link-layer address=20 > resolution until > you've done the forwarding table lookup and done on-link=20 > determination. =3D> I'll try to answer all of the above here if possible: The text does not say that you should do address resolution=20 before consulting your neighbor cache or forwarding table and do on-link determination. Although, this can probably be made clearer.=20 So, I think the clarification needed is in the order of steps. I.e. The current text seems to skip a couple of steps. >=20 > >=20 > > In any case, this issue was discussed with Jinmei last week and=20 > > here is the suggested text that we agreed on. Please let me know > > if you have a comment: > >=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. >=20 > The same argument does not apply to single homed nodes. The point of > removing the on-link assumption was to make sure the node=20 > does _not_ do > address resolution in the absence of a route to the destination. Are > you saying that it's ok to do that if you have more than one network > interface? That's how I read this text. =3D> You seem to make this assumption because the text does not = explicitly spell out the order of events. Would it be clearer if the text explains=20 that address resolution is only done if the on-link determination=20 process indicates that the destination is onlink? If you agree with this = I can send suggested text. Hesham >=20 > -Seb >=20 >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 14:22:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXrA-00026g-0z; Wed, 01 Jun 2005 14:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXr7-00020x-JF for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 14:22: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 OAA12234 for ; Wed, 1 Jun 2005 14:22:13 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYAz-000213-JT for ipv6@ietf.org; Wed, 01 Jun 2005 14:42:50 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j51IM7jU004376 for ; Wed, 1 Jun 2005 12:22:16 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHF000014CWB8@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for ipv6@ietf.org; Wed, 01 Jun 2005 14:22:15 -0400 (EDT) Received: from 129.148.174.103 (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IHF00DGT4D251@bur-mail2.east.sun.com>; Wed, 01 Jun 2005 14:22:15 -0400 (EDT) Date: Wed, 01 Jun 2005 14:22:14 -0400 From: Sebastien Roy In-reply-to: To: "Soliman, Hesham" Message-id: <1117650134.7273.30.camel@strat> Organization: Solaris Network & Security Technologies, Sun Microsystems MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT 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, 2005-06-01 at 14:11, Soliman, Hesham wrote: > The text does not say that you should do address resolution > before consulting your neighbor cache or forwarding table and do > on-link determination. Although, this can probably be made clearer. > So, I think the clarification needed is in the order of steps. I.e. > The current text seems to skip a couple of steps. Maybe, but I don't see the need for the text at all. If implementors want to play cute games with ND, then let them. > => You seem to make this assumption because the text does not explicitly > spell out the order of events. Would it be clearer if the text explains > that address resolution is only done if the on-link determination > process indicates that the destination is onlink? If you agree with this > I can send suggested text. It would be better than what's there now, but ideally, the text should just be removed entirely. Doing address resolution on multiple links can lead to ambiguous results. There could be multiple destinations responding to the same address, and you don't know which one you're talking to. This hasn't been studied enough to even be mentioned. If particular implementations want to do this, they can. There's nothing in the spec that prevents them from doing it. Please consider removing the text as Jinmei has already suggested in previous posts (and I apologize for having missed those messages last week). Thanks, -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 14:29:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXyI-0004QY-5v; Wed, 01 Jun 2005 14: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 1DdXyF-0004QT-VG for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 14:29: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 OAA12726 for ; Wed, 1 Jun 2005 14:29:36 -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 1DdYI8-0002S3-2u for ipv6@ietf.org; Wed, 01 Jun 2005 14:50:12 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Jun 2005 14:29:30 -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, 1 Jun 2005 14:29:29 -0400 Message-ID: Thread-Topic: 2461bis update Thread-Index: AcVm1tbbO73pTS4LT/yXvCaW1YQ7LwAALyEA From: "Soliman, Hesham" To: "Sebastien Roy" X-OriginalArrivalTime: 01 Jun 2005 18:29:31.0057 (UTC) FILETIME=[D9F3EA10:01C566D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > It would be better than what's there now, but ideally, the=20 > text should > just be removed entirely. =20 Doing address resolution on multiple links > can lead to ambiguous results. There could be multiple destinations > responding to the same address, and you don't know which one you're > talking to. This hasn't been studied enough to even be=20 > mentioned.=20 =3D> Agreed. That's why it's in an appendix. Anyway, if no one has a = problem with removing this text I'm fine with removing it.=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 Jun 01 14:37:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY6D-00085S-75; Wed, 01 Jun 2005 14:37:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY6B-000852-Iy for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 14:37: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 OAA13527 for ; Wed, 1 Jun 2005 14:37:47 -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 1DdYQ2-0002oX-FK for ipv6@ietf.org; Wed, 01 Jun 2005 14:58:24 -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 j51IbWp19609; Wed, 1 Jun 2005 11:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alerion.mentat.com (Postfix) with ESMTP id 09BAF3F0021; Wed, 1 Jun 2005 11:37:33 -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 05657-04; Wed, 1 Jun 2005 11:37:24 -0700 (PDT) Received: from feller (feller [192.88.122.144]) by alerion.mentat.com (Postfix) with ESMTP id 5FCA63F0020; Wed, 1 Jun 2005 11:37:24 -0700 (PDT) From: Tim Hartrick To: "Soliman, Hesham" In-Reply-To: <53180ed26fc39e38633239b5efdec977@message.md5> References: <53180ed26fc39e38633239b5efdec977@message.md5> Content-Type: text/plain Organization: Mentat Inc. Message-Id: <1117651038.26460.10.camel@feller> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 01 Jun 2005 11:37:18 -0700 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Sebastien Roy Subject: RE: 2461bis update 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 On Wed, 2005-06-01 at 11:29, Soliman, Hesham wrote: > > It would be better than what's there now, but ideally, the > > text should > > just be removed entirely. > > Doing address resolution on multiple links > > can lead to ambiguous results. There could be multiple destinations > > responding to the same address, and you don't know which one you're > > talking to. This hasn't been studied enough to even be > > mentioned. > > => Agreed. That's why it's in an appendix. Anyway, if no one has a problem > with removing this text I'm fine with removing it. > I agree that it should be removed. It seems completely out of place given that the on-link assumption has been removed from the specification. tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 14:40:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY8O-0000z1-UW; Wed, 01 Jun 2005 14:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY8O-0000xd-3L for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 14:40: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 OAA13841 for ; Wed, 1 Jun 2005 14:40:04 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYSF-00031F-Bf for ipv6@ietf.org; Wed, 01 Jun 2005 15:00:40 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j51Ie4ol012248 for ; Wed, 1 Jun 2005 11:40:05 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHF00701564FP@bur-mail2.east.sun.com> (original mail from Sebastien.Roy@Sun.COM) for ipv6@ietf.org; Wed, 01 Jun 2005 14:40:04 -0400 (EDT) Received: from 129.148.174.103 (strat.East.Sun.COM [129.148.174.103]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IHF00D4H56S51@bur-mail2.east.sun.com>; Wed, 01 Jun 2005 14:40:04 -0400 (EDT) Date: Wed, 01 Jun 2005 14:40:04 -0400 From: Sebastien Roy In-reply-to: To: "Soliman, Hesham" Message-id: <1117651204.7273.35.camel@strat> Organization: Solaris Network & Security Technologies, Sun Microsystems MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7BIT 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, 2005-06-01 at 14:29, Soliman, Hesham wrote: > => Agreed. That's why it's in an appendix. Anyway, if no one has a problem > with removing this text I'm fine with removing it. Thanks Hesham, -Seb -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 15:43:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZ7r-00083L-JD; Wed, 01 Jun 2005 15:43:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZ7o-00082n-MZ; Wed, 01 Jun 2005 15:43: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 PAA20544; Wed, 1 Jun 2005 15:43:34 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdZRg-0006cw-H3; Wed, 01 Jun 2005 16:04:09 -0400 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 20:43:25 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Jun 2005 20:43:25 +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: Wed, 1 Jun 2005 20:43:24 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A700F3C8811@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] Re: purpose of m/o bit Thread-Index: AcVmw/9IMuFC38IaQamHgpoSqZW+2QAHZIAA To: X-OriginalArrivalTime: 01 Jun 2005 19:43:25.0160 (UTC) FILETIME=[2CE25680:01C566E2] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, ipv6@ietf.org, pekkas@netcore.fi, rdroms@cisco.com 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 Mohacsi Janos wrote: > On Wed, 1 Jun 2005 matthew.ford@bt.com wrote: >=20 >> dhcwg-bounces@ietf.org wrote: >>> On Wed, 1 Jun 2005, Ralph Droms wrote: >>>> 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 >>>=20 >>> It would be even better to keep backward compatibility, i.e., not >>> require extensions to ICB-only DHCP servers to support Solicits. >>> Let's face it, those extensions always take time to specify, code >>> and deploy, the admins will have to wait for new versions, etc. >>=20 >> What admins? Several posts in this thread indicate that there is >> little if any production deployment of DHCPv6 right now. >>=20 >=20 > This not true. There are several systems are using DHCPv6 to > distribute DNS server information via IPv6. We also use this > capability for more than one year in production. Like I said, 'little ... production deployment'. > Keeping combatibility to some extent, is always a golden rule Agreed, but this case may be an exception to prove the rule. -- Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 18:27:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdbgU-0006rf-Vc; Wed, 01 Jun 2005 18:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdbgT-0006r5-Kl; Wed, 01 Jun 2005 18:27: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 SAA15755; Wed, 1 Jun 2005 18:27:30 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddc0N-0002O0-OE; Wed, 01 Jun 2005 18:48:08 -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 j51MRWmJ012287 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 2 Jun 2005 00:27:32 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <8E296595B6471A4689555D5D725EBB213391C0@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: <6932AED4-E00B-4938-821E-8A4997FA727F@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 2 Jun 2005 00:27:26 +0200 To: Iljitsch van Beijnum 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: 52f7a77164458f8c7b36b66787c853da 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 1-jun-2005, at 18:24, Iljitsch van Beijnum wrote: [always cool following up on your on posts...] Because I fell in the middle of this discussion, and there seems to be a rather substantial disconnect between my views and those of many others, I decided to read up on earlier posts a bit. I must say that I'm somewhat concerned by what I saw. A prevalent position was "let the administrators figure it out, this isn't the IETF's business". I strongly disagree here. We're talking about AUTOconfiguration here. Obviously, administrators should always be free to configure their networks in any way that pleases them. However, in order for good things to happen AUTOMATICALLY, it's necessary that administrators can predict the default out of the box behavior of hosts, so that they can set up their equipment to make those hosts work well in their network. The fundamental issue here is the question whether it's ok to ALWAYS do DHCPv6. I don't think that the position that this is the case is a reasonable one, because: - it wastes bandwidth which is harmful in bandwidth and/or power constrained environments - it makes it impossible to get consistent behavior from a set of hosts that include hosts that do implement DHCPv6 and hosts that don't implement DHCPv6 - it allows the introduction of rogue DHCPv6 servers in otherwise secure environments (rogue DHCP servers are a big problem in ad-hoc IPv4 networks) - it makes it harder to contain the bad effects of incorrectly operating DHCPv6 servers (I believe it's very easy for DHCPv6 servers to assign addresses that are inconsistent with router configurations and thus not routable) So if doing DHCPv6 in all cases isn't acceptable, we clearly need very specific guidelines about when DHCPv6 MAY or SHOULD be used and when it MUST NOT be used. We desperately need to avoid the situation where people are forced to filter out DHCPv6 packets because it's the only way from stopping hosts from doing DHCPv6 out of the box. Note that any comparison to DHCP in IPv4 is meaningless as there is no stateless autoconfiguration in IPv4. DHCP is ubiquitous in IPv4, but it's almost inconceivable that it will attain the same status in IPv6. This means the protocol has to know when to bow out gracefully. In the mean time, the dhc working group has come up with two variations of DHCPv6 which aren't interoperable: the stateful version that uses Solicit messages, and the stateless version that uses Information-Request messages. It is obviously harmful to have a network that only has servers that support the stateful variant and then have hosts that only use the stateless variant, or the other way around. The situation where both variants are executed simultaneously, or when one is tried first and the other afterwards, are also problematic because of unnecessary extra bandwidth use or additional delays. Mandating that servers forever support both variations is probably the least harmful solution, but it's still less than optimal. Clear guidelines about which DHCPv6 variation MUST be used in which situation is clearly beneficial here. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 01 19:11:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdcN5-00070g-QY; Wed, 01 Jun 2005 19:11:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdcN2-0006xK-8O for ipv6@megatron.ietf.org; Wed, 01 Jun 2005 19:11: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 TAA19065 for ; Wed, 1 Jun 2005 19:11:28 -0400 (EDT) Received: from web90106.mail.scd.yahoo.com ([66.218.94.77]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ddcgw-0004ce-Rn for ipv6@ietf.org; Wed, 01 Jun 2005 19:32:07 -0400 Received: (qmail 1149 invoked by uid 60001); 1 Jun 2005 23:11:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U7w53zm8d67RBSPxpNGcTgStgCQIaYJnoAsiEh8GXjipg3W9bN3U2+t9nmc8VnZSvDhEMCEketpWyRsxo2D7W4tRzJANQKfz6JjIG9NvY87HrL/hoB61+sIKDPBz3LjbRW+1iVsv8+96+ERu47hg3HwL2y8zYllnp9raZmtZV48= ; Message-ID: <20050601231122.1147.qmail@web90106.mail.scd.yahoo.com> Received: from [47.234.0.52] by web90106.mail.scd.yahoo.com via HTTP; Wed, 01 Jun 2005 16:11:22 PDT Date: Wed, 1 Jun 2005 16:11:22 -0700 (PDT) From: Derek Smalls To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Subject: I/F ID uniqueness and 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 There seems to be a slight inconsistency in rfc2462bis regarding the uniqueness of interface identifiers on an interface. >From Section 5.4: " .. new types of addresses have been introduced where the interface identifiers are not necessarily the same for all unicast addresses on a single interface [RFC3041] [RFC3972]. " However, clause d) in Section 5.5.3 makes references to "link's interface identifier" and seems to assume that a given IPv6 interface has a single interface identifier. Will this algorithm work if there are multiple interface identifiers on a given interface? __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 02 08:43:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddp2i-0005wd-95; Thu, 02 Jun 2005 08:43:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddp2e-0005wY-Vv for ipv6@megatron.ietf.org; Thu, 02 Jun 2005 08:43: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 IAA10247 for ; Thu, 2 Jun 2005 08:43:19 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdpMf-0002qQ-9p for ipv6@ietf.org; Thu, 02 Jun 2005 09:04:02 -0400 Received: from ep_mmp1 (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 <0IHG00LGGJBWQG@mailout3.samsung.com> for ipv6@ietf.org; Thu, 02 Jun 2005 21:43:08 +0900 (KST) Received: from srkrishnan ([107.108.71.58]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHG00GNZJBT5U@mmp1.samsung.com> for ipv6@ietf.org; Thu, 02 Jun 2005 21:43:08 +0900 (KST) Date: Thu, 02 Jun 2005 18:10:51 +0530 From: "Radhakrishnan.S" To: Sebastien Roy , H.Soliman@flarion.com Message-id: <044c01c56770$513d5820$3a476c6b@sisodomain.com> Organization: Samsung India Software Operations 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: <1117650134.7273.30.camel@strat> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: Re: 2461bis update X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Radhakrishnan.S" List-Id: "IP 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 consider removing the text as Jinmei has already suggested in > previous posts (and I apologize for having missed those messages last > week). Even i support the removal of text. I had raised this during a discussion in v6ops mailing list and Jinmei had told that time its getting removed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 02 11:23:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdrY4-0002p4-FR; Thu, 02 Jun 2005 11:23:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdrY1-0002oI-Or; Thu, 02 Jun 2005 11:23: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 LAA25744; Thu, 2 Jun 2005 11:23:51 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddrs3-0003XT-TB; Thu, 02 Jun 2005 11:44:37 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id E9C0D20000F6; Thu, 2 Jun 2005 11:23:34 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 11:23:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jun 2005 11:23:30 -0400 Message-ID: <936A4045C332714F975800409DE092405EB9CC@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnFiDL/H0oVNoJSmarjTpBo4NEjwAcLMSw From: "Bound, Jim" To: "Christian Schild" , , X-OriginalArrivalTime: 02 Jun 2005 15:23:34.0864 (UTC) FILETIME=[0AC1B500:01C56787] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 =20 > 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. So you don't believe that the RA in ND should be the authority to use a stateful model on an IPv6 link? /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 02 11:47:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddrub-0000dG-0r; Thu, 02 Jun 2005 11:47:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdruY-0000bw-Bj; Thu, 02 Jun 2005 11:47: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 LAA00074; Thu, 2 Jun 2005 11:47:07 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdsEa-00053P-As; Thu, 02 Jun 2005 12:07:53 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 16:46:58 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Jun 2005 16:46:58 +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: Thu, 2 Jun 2005 16:46:56 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A700F3C8F89@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnFiDL/H0oVNoJSmarjTpBo4NEjwAcLMSwAACyYrA= To: , , , X-OriginalArrivalTime: 02 Jun 2005 15:46:58.0263 (UTC) FILETIME=[4F3F6670:01C5678A] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 ipv6-bounces@ietf.org wrote: >> 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. >=20 > So you don't believe that the RA in ND should be the > authority to use a > stateful model on an IPv6 link? stateful/stateless is of no concern to the client, right? so if the initiator is always the same, then the question of authority becomes moot. -- Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 02 12:01:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dds8d-0001jY-5U; Thu, 02 Jun 2005 12:01:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dds8a-0001jF-Jx for ipv6@megatron.ietf.org; Thu, 02 Jun 2005 12:01: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 MAA01818 for ; Thu, 2 Jun 2005 12:01:37 -0400 (EDT) From: timbeck04@verizon.net Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdsSb-0005wW-73 for ipv6@ietf.org; Thu, 02 Jun 2005 12:22:24 -0400 Received: from vms062.mailsrvcs.net ([192.168.1.3]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IHG0061LSIKF6J2@vms042.mailsrvcs.net> for ipv6@ietf.org; Thu, 02 Jun 2005 11:01:32 -0500 (CDT) Date: Thu, 02 Jun 2005 11:01:32 -0500 (CDT) To: ipv6@ietf.org Message-id: <23049152.1117728092907.JavaMail.root@vms062.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: draft-ietf-ipv6-privacy-addrs-v2-04 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Good morning all. I'm aware this draft is in AD Review/AD Follow-up status, and hope this is an appropriate time to raise questions (none being rhetorical) and issues. I'd greatly appreciate technical group feedback on the following: ___ In section 3, it is stated 'Deprecated addresses can continue to be used for already established connections...'. In section 3.6 it is stated '... some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions but expects them all to use the same addresses.' It seems to me that given section 3., the only times when the section 3.6 statement would likely be true is if a session is terminated, then a new one is established. ___ In section 3.5, it is stated 'The value DESYNC_FACTOR is a random value (different for each client) that ensures that clients don't synchronize with each other and generate new addresses at exactly the same time.' How do we really know if DESYNC_VALUE will be different for each client? The answer doesn't seem to be in this draft. Presuming DESYNC_VALUE to be an integer (0=lower bound, 600 seconds=MAX_DESYNC_FACTOR=upper bound), there would only be 601 possible values. Thus it seems to me the random number generator used to determine this value is fairly limited. ___ Including in section 5., regarding both the TEMP_VALID_LIFETIME and the TEMP_PREFERRED_LIFETIME values: 'Users should be able to override the default value.' Is the network administrator able to override values set by users? It seems to me administrators should have that ability. ___ Best regards, Tim Enos 1Sam16:7 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 02 12:22:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsSh-0005Ed-Mr; Thu, 02 Jun 2005 12:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsSf-0005ES-Ia for ipv6@megatron.ietf.org; Thu, 02 Jun 2005 12:22: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 MAA03925 for ; Thu, 2 Jun 2005 12:22:22 -0400 (EDT) From: timbeck04@verizon.net Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddsmj-0007BI-Dx for ipv6@ietf.org; Thu, 02 Jun 2005 12:43:09 -0400 Received: from vms062.mailsrvcs.net ([192.168.1.3]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IHG0067MTHCC7T2@vms042.mailsrvcs.net> for ipv6@ietf.org; Thu, 02 Jun 2005 11:22:24 -0500 (CDT) Date: Thu, 02 Jun 2005 11:22:24 -0500 (CDT) To: timbeck04@verizon.net, ipv6@ietf.org Message-id: <7101657.1117729344517.JavaMail.root@vms062.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Subject: Re: draft-ietf-ipv6-privacy-addrs-v2-04 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 meant to write DESYNC_FACTOR where you see DESYNC_VALUE in the original mail below. Sorry for the typo! :) >From: timbeck04@verizon.net >Date: Thu Jun 02 11:01:32 CDT 2005 >To: ipv6@ietf.org >Subject: draft-ietf-ipv6-privacy-addrs-v2-04 >Good morning all. I'm aware this draft is in AD Review/AD Follow-up status, and hope this is an appropriate time to raise questions (none being rhetorical) and issues. I'd greatly appreciate technical group feedback on the following: > >___ > >In section 3, it is stated 'Deprecated addresses can continue to be used for already established connections...'. In section 3.6 it is stated '... some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions but expects them all to use the same addresses.' > >It seems to me that given section 3., the only times when the section 3.6 statement would likely be true is if a session is terminated, then a new one is established. > >___ > >In section 3.5, it is stated 'The value DESYNC_FACTOR is a random value (different for each client) that ensures that clients don't synchronize with each other and generate new addresses at exactly the same time.' > >How do we really know if DESYNC_VALUE will be different for each client? The answer doesn't seem to be in this draft. > >Presuming DESYNC_VALUE to be an integer (0=lower bound, 600 seconds=MAX_DESYNC_FACTOR=upper bound), there would only be 601 possible values. Thus it seems to me the random number generator used to determine this value is fairly limited. > >___ > >Including in section 5., regarding both the TEMP_VALID_LIFETIME and the TEMP_PREFERRED_LIFETIME values: 'Users should be able to override the default value.' Is the network administrator able to override values set by users? It seems to me administrators should have that ability. > >___ > >Best regards, > >Tim Enos >1Sam16: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 Thu Jun 02 12:24:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsV2-0006MN-Ji; Thu, 02 Jun 2005 12:24:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsV0-0006Ll-26; Thu, 02 Jun 2005 12:24: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 MAA04122; Thu, 2 Jun 2005 12:24:47 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddsp2-0007LB-Rn; Thu, 02 Jun 2005 12:45:34 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A2C59200013A; Thu, 2 Jun 2005 12:24: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); Thu, 2 Jun 2005 12:23: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: Thu, 2 Jun 2005 12:23:37 -0400 Message-ID: <936A4045C332714F975800409DE092405EBA1E@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnFiDL/H0oVNoJSmarjTpBo4NEjwAcLMSwAACyYrAAASHZYA== From: "Bound, Jim" To: , , , X-OriginalArrivalTime: 02 Jun 2005 16:23:38.0507 (UTC) FILETIME=[6EB1FDB0:01C5678F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Mat, > stateful/stateless is of no concern to the client, right? so if the > initiator is always the same, then the question of authority becomes > moot. Let me restate I don't think you parsed my question, which may have been unclear in hingsight? For an IPv6 link the RA informs nodes whether they are permitted to use stateful, the default preference is stateless, meaning DO NOT USE DHCPv6 for anything, unless I set a bit that informs you that your permitted to use stateful on this link. This means the client after getting A bit set, and M/O bits not set, and prefix list it does not execute DHCPv6 client code at all. This is what I mean't by authority of RA to the client. Do you disagree with that the IPv6 Link uses this model. =20 The way most implementations I am aware of work is as follows as hosts: If 'A' bit set with prefixes provided, set prefix list/lifetimes to on, and configure addresses from prefix with EUI. THEN check: If 'M' or 'O' bit set then call dhcpv6 client thread, or however engnineer wanted to implement this, ELSE dhcpv6 is not called. 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 Thu Jun 02 15:05:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddv0m-0000Sx-Ha; Thu, 02 Jun 2005 15:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddv0k-0000Ss-AP for ipv6@megatron.ietf.org; Thu, 02 Jun 2005 15:05: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 PAA17765 for ; Thu, 2 Jun 2005 15:05:44 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdvKo-0005c8-Bp for ipv6@ietf.org; Thu, 02 Jun 2005 15:26:31 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:e083:3191:14d:bd2]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 79E551521B; Fri, 3 Jun 2005 04:08:41 +0900 (JST) Date: Fri, 03 Jun 2005 04:06:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Derek Smalls In-Reply-To: <20050601231122.1147.qmail@web90106.mail.scd.yahoo.com> References: <20050601231122.1147.qmail@web90106.mail.scd.yahoo.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: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipv6@ietf.org Subject: Re: I/F ID uniqueness and 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 Wed, 1 Jun 2005 16:11:22 -0700 (PDT), >>>>> Derek Smalls said: > There seems to be a slight inconsistency in rfc2462bis > regarding the uniqueness of interface identifiers on > an interface. >> From Section 5.4: > " .. new types of addresses have been introduced where > the interface identifiers are not necessarily the same > for all unicast addresses on a single interface > [RFC3041] [RFC3972]. " > However, clause d) in Section 5.5.3 makes references > to "link's interface identifier" and seems to assume > that a given IPv6 interface has a single interface > identifier. Will this algorithm work if there are > multiple interface identifiers on a given interface? The short answer is YES. As you used the word "slight", I'm not sure if this requires a change to the rfc2462bis text, but I don't mind revising Section 5.5.3 to, e.g.: 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) by combining the advertised prefix with an interface identifier of the link as follows: People may still wonder what the host should do if there are multiple interface identifiers, and they might think rfc2462bis should clearly specify the behavior. However, I personally think it's overkilling for rfc2462bis. After all, the most typical case is that the host uses the single interface identifier derived from the interface's link-layer address. And the specifications using additional identifiers ([RFC3041] or [RFC3972]) describes how to form addresses with the additional identifiers inside the specific documents. Summarizing the above, I see three options: 1. just leave the current text as is. (since the "issue" is very minor) 2. introduce a minor modification, replacing "the interface identifier" with "an interface identifier" wherever appropriate. 3. in addition to option 2, add detailed description about how the host should do if it has multiple interface identifiers I can live with either 1 or 2, but I think option 3 is overkilling. Opinions? 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 Jun 02 18:01:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxkU-0003lw-B5; Thu, 02 Jun 2005 18:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxkS-0003kb-BS; Thu, 02 Jun 2005 18:01: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 SAA04372; Thu, 2 Jun 2005 18:01:05 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddy4X-0002XF-Rg; Thu, 02 Jun 2005 18:21:55 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA29962; Thu, 2 Jun 2005 15:00:54 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j52M0sn29467; Thu, 2 Jun 2005 15:00:54 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 15:00:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jun 2005 15:00:53 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4E91@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: RE: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnvov0pm+k/tCmS3eET6Nf/U2JWQ== From: "Templin, Fred L" To: "Bound, Jim" , "Christian Schild" , , X-OriginalArrivalTime: 02 Jun 2005 22:00:54.0471 (UTC) FILETIME=[8C450D70:01C567BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Jim et al, At the risk of covering old ground, one question I had is whether a = client must wait to receive an RA before initiating stateless or = stateful DHCPv6? Asked another way, can DHCPv6 still be used if there = are no advertising routers on the link? To an even more speculative question, if we had it all to do over again = would it be possible (or desireable) to design things such that DHCPv6 = and IPv6 ND messages could be "piggybacked" within a single packet? = (This begs the question of whether the DHCPv6 server/relay and IPv6 = router entities are co-resident on the same node in the normal case.) Fred fred.l.templin@boeing.com =20 "Bound, Jim" wrote: > > 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. > > So you don't believe that the RA in ND should be the authority to use = a > stateful model on an IPv6 link? > > /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 Jun 03 00:04:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De3Q8-0004Ve-1e; Fri, 03 Jun 2005 00:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De3Q3-0004V7-HQ; Fri, 03 Jun 2005 00:04: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 AAA25739; Fri, 3 Jun 2005 00:04:24 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De3kC-00011e-DI; Fri, 03 Jun 2005 00:25:17 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id E556320000FE; Fri, 3 Jun 2005 00:04:01 -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, 3 Jun 2005 00:04: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, 3 Jun 2005 00:04:00 -0400 Message-ID: <936A4045C332714F975800409DE092405EBC4C@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnvov0pm+k/tCmS3eET6Nf/U2JWQAMUcPg From: "Bound, Jim" To: "Templin, Fred L" , "Christian Schild" , , X-OriginalArrivalTime: 03 Jun 2005 04:04:01.0779 (UTC) FILETIME=[46846C30:01C567F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Fred, Good questions. But could cause gigantic rat-hole :--) > At the risk of covering old ground, one question I had is=20 > whether a client must wait to receive an RA before initiating=20 > stateless or stateful DHCPv6? Asked another way, can DHCPv6=20 > still be used if there are no advertising routers on the link? To get prefixes yes, and to use them the A bit should be set. But IPv6 is stateless in the node. The node creates the link-local and then DAD on the network. Though I think shutting DAD off completely in some environments is now prudent for some users special networks. =20 >=20 > To an even more speculative question, if we had it all to do=20 > over again would it be possible (or desireable) to design=20 > things such that DHCPv6 and IPv6 ND messages could be=20 > "piggybacked" within a single packet? (This begs the question=20 > of whether the DHCPv6 server/relay and IPv6 router entities=20 > are co-resident on the same node in the normal case.) Two questions really. On piggy-back I don't think so for me. Stateless is the win for IP from the efforts for IPv6, and permeates its technical and operational benefits for networks, DHCP is stateful and means some server function exists that has state. I support the model now and the authority plane of stateless or stateful model via the A bit and then stating to use or not use stateful. As far as co-locating the functions that is an implementation choice and we should not speculate on implementation of that nature between routers vs. hosts. vs. servers. vs clients, when building a standard on this topic. Also can start an anti-trust problem :--). So I say let the market decide on that one. I don't think its a good idea personally speaking strictly as individual knowing both routers and hosts as IP stack architecture and their purpose in my view. I think its pretty simple and backwards compatibility for ND and addrconf is drop the o bit and keep the m bit see my previous suggestion on this sent a day or so ago. thanks /jim =20 >=20 > Fred > fred.l.templin@boeing.com =20 >=20 > "Bound, Jim" wrote: > > > 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=20 > simply initiate > > > a(n Information) Request message and would get all the information > > > that are available on the link, including an address or not. > > > > So you don't believe that the RA in ND should be the=20 > authority to use a > > stateful model on an IPv6 link? > > > > /jim >=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 Jun 03 00:24:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De3jf-0006N1-TZ; Fri, 03 Jun 2005 00:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De3jd-0006Mw-PW for ipv6@megatron.ietf.org; Fri, 03 Jun 2005 00:24: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 AAA26768 for ; Fri, 3 Jun 2005 00:24:38 -0400 (EDT) Received: from web90108.mail.scd.yahoo.com ([66.218.94.79]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1De43n-0001QM-MK for ipv6@ietf.org; Fri, 03 Jun 2005 00:45:32 -0400 Received: (qmail 7780 invoked by uid 60001); 3 Jun 2005 04:24:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JyA+FZTOvKS3dGyPf4MhCkzD+X25x6z67MSrXdZfbTyhnXbAhB4N+Re0sFmU5+mDoJ3VdiFbsjytzdy778VFCt7Yl9Tm6MHNegvPipT/QjA0o5iYBqJ4DvCR1fUWe3J8aD2jnwANck/1Ehb/l1satdL7QswN+fYCwXpMNoh+GKk= ; Message-ID: <20050603042432.7778.qmail@web90108.mail.scd.yahoo.com> Received: from [66.30.192.80] by web90108.mail.scd.yahoo.com via HTTP; Thu, 02 Jun 2005 21:24:31 PDT Date: Thu, 2 Jun 2005 21:24:31 -0700 (PDT) From: Derek Smalls To: jinmei@isl.rdc.toshiba.co.jp, Derek Smalls In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 2.4 (++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org Subject: Re: I/F ID uniqueness and 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 I think option 2 is the best. The standards the way they are today are quite vague on the uniqueness of interfaces IDs on an interface, uniqueness of advertised prefixes across multiple links etc. It's best to reduce ambiguity as much as possible. --- JINMEI Tatuya / $B?@L@C#:H(B wrote: > >>>>> On Wed, 1 Jun 2005 16:11:22 -0700 (PDT), > >>>>> Derek Smalls said: > > > There seems to be a slight inconsistency in > rfc2462bis > > regarding the uniqueness of interface identifiers > on > > an interface. > > >> From Section 5.4: > > " .. new types of addresses have been introduced > where > > the interface identifiers are not necessarily the > same > > for all unicast addresses on a single interface > > [RFC3041] [RFC3972]. " > > > However, clause d) in Section 5.5.3 makes > references > > to "link's interface identifier" and seems to > assume > > that a given IPv6 interface has a single interface > > identifier. Will this algorithm work if there are > > multiple interface identifiers on a given > interface? > > The short answer is YES. > > As you used the word "slight", I'm not sure if this > requires a change > to the rfc2462bis text, but I don't mind revising > Section 5.5.3 to, > e.g.: > > 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) by combining > the advertised > prefix with an interface identifier of the > link as follows: > > People may still wonder what the host should do if > there are multiple > interface identifiers, and they might think > rfc2462bis should clearly > specify the behavior. However, I personally think > it's overkilling > for rfc2462bis. After all, the most typical case is > that the host > uses the single interface identifier derived from > the interface's > link-layer address. And the specifications using > additional > identifiers ([RFC3041] or [RFC3972]) describes how > to form addresses > with the additional identifiers inside the specific > documents. > > Summarizing the above, I see three options: > > 1. just leave the current text as is. (since the > "issue" is very > minor) > 2. introduce a minor modification, replacing "the > interface > identifier" with "an interface identifier" > wherever appropriate. > 3. in addition to option 2, add detailed description > about how the > host should do if it has multiple interface > identifiers > > I can live with either 1 or 2, but I think option 3 > is overkilling. > > Opinions? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > __________________________________ Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 03 02: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 1De5p8-00017u-Go; Fri, 03 Jun 2005 02: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 1De5p4-00015k-V0; Fri, 03 Jun 2005 02:38: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 CAA26820; Fri, 3 Jun 2005 02:38:25 -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 1De69G-0003yH-21; Fri, 03 Jun 2005 02:59:18 -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 j536cF1q029864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 3 Jun 2005 08:38:15 +0200 (CEST) From: Christian Schild To: "Bound, Jim" In-Reply-To: <936A4045C332714F975800409DE092405EBA1E@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092405EBA1E@tayexc14.americas.cpqcorp.net> Content-Type: text/plain Date: Fri, 03 Jun 2005 08:38:12 +0200 Message-Id: <1117780692.31317.277.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: 31247fb3be228bb596db9127becad0bc 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 Hi Jim, Am Donnerstag, den 02.06.2005, 12:23 -0400 schrieb Bound, Jim: > > So you don't believe that the RA in ND should be the authority to > > use a stateful model on an IPv6 link? Thanks for your question, I think that's a key part of the discussion. I know what you are trying to achieve. As a network admin it is a really desirable goal to be in control of the clients to send DHCPv6 messages or not. This control in fact could be achieved with a proper definition and usage of the M/O bit(s). But: > > stateful/stateless is of no concern to the client, right? so if the > > initiator is always the same, then the question of authority becomes > > moot. > > Let me restate I don't think you parsed my question, which may have been > unclear in hingsight? > > For an IPv6 link the RA informs nodes whether they are permitted to use > stateful, the default preference is stateless, meaning DO NOT USE DHCPv6 > for anything, unless I set a bit that informs you that your permitted to > use stateful on this link. > > This means the client after getting A bit set, and M/O bits not set, and > prefix list it does not execute DHCPv6 client code at all. > > This is what I mean't by authority of RA to the client. > > Do you disagree with that the IPv6 Link uses this model. > > The way most implementations I am aware of work is as follows as hosts: > > If 'A' bit set with prefixes provided, set prefix list/lifetimes to on, > and configure addresses from prefix with EUI. > > THEN check: > > If 'M' or 'O' bit set then call dhcpv6 client thread, or however > engnineer wanted to implement this, ELSE dhcpv6 is not called. This is the ideal scenario, yes. (side note: I think we agree, that a client is allowed to do dhcpv6 in the lack of RAs?) I think this scenario might fail, because: Client (needing addresses and information) and routers (sending RAs) are two different entities with their own set of behaviours and their own set of wishes. In your model you are trying to force the client to do something what the router wants. Fine with me, but I don't believe that suppression of (client) DHCPv6 packets is enforceable. What if the client is not pleased with what he got? E.g.: The client desperately needs an additional information, lets say an NTP server. Maybe because an application needs it. The client may get the idea "ok, I'm not allowed to do DHCPv6, but I really really need that information" so it will launch DHCPv6. NTP is just an example. E.g.: What if the client is not pleased with the address he got. E.g. he only got a ULA prefix via the RA and wants to communicate with the global network. Then the client may probe if there are more and better prefixes available in DHCPv6. This can even get initiated by a user (!). I hope you know what I'm trying to say. The really dangerous part in your model is, that a network administrator may get the impression, that now that DHCPv6 is disable on that link (M=0,O=0), nothing on that link will use it. As shown above, this may not be true, it is not enforceable. And my conclusion to this: If we really want to use the M/O bits, then please make them just hints. A SHOULD is good, a MUST is too strong. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 03 04: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 1De77G-0006Aj-L6; Fri, 03 Jun 2005 04: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 1De77D-0006Ab-V2; Fri, 03 Jun 2005 04:01: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 EAA01712; Fri, 3 Jun 2005 04:01:14 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De7RO-0005ZR-Ru; Fri, 03 Jun 2005 04:22:08 -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 j5380wTJ037002 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 3 Jun 2005 10:01:00 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4E91@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4E91@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <60F2BC21-BD7D-4084-A467-C86D54563D27@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 3 Jun 2005 10:00:50 +0200 To: "Templin, Fred L" 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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 3-jun-2005, at 0:00, Templin, Fred L wrote: > At the risk of covering old ground, Yeah, we wouldn't want that. :-) > one question I had is whether a client must wait to receive an RA > before initiating stateless or stateful DHCPv6? How would it know the value of the M and O bits if it didn't? > Asked another way, can DHCPv6 still be used if there are no > advertising routers on the link? I suppose nothing is impossible, but it won't buy you much. If you get an address, you can't use it, since DHCPv6 can't provide a default gateway, like DHCPv4 does. Being able to learn additional information is of questionable value, using multicast DNS / zeroconf would be much more appropriate in an environment where there is no global connectivity. > To an even more speculative question, if we had it all to do over > again would it be possible (or desireable) to design things such > that DHCPv6 and IPv6 ND messages could be "piggybacked" within a > single packet? There is obvious synergy here. I think we can still do this, and it could be very simple: define a new RA/ND option that carries DHCPv6 options. Routers could inject locally configured information, or do some form of stateless DHCPv6 and copy the results to RAs. (Stateful information must not leak out through RAs, of course.) Note that information in RAs is broadcast periodically so it takes up some bandwidth regardless of whether it's needed. On the other hand, hosts don't have to query for this information individually, which saves bandwidth, especially on a shared medium such as 802.11. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 03 04:14:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De7K1-0003gV-EJ; Fri, 03 Jun 2005 04:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De7Jq-0003gI-4d; Fri, 03 Jun 2005 04:14: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 EAA02420; Fri, 3 Jun 2005 04:14:16 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De7e2-0005qw-7a; Fri, 03 Jun 2005 04:35:10 -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 j538EGTJ037170 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 3 Jun 2005 10:14:16 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <1117780692.31317.277.camel@lemy.ipv6.uni-muenster.de> References: <936A4045C332714F975800409DE092405EBA1E@tayexc14.americas.cpqcorp.net> <1117780692.31317.277.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: <995080F4-16F7-4B26-BC1D-A3DA040715B7@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Fri, 3 Jun 2005 10:14:08 +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: d17f825e43c9aed4fd65b7edddddec89 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 3-jun-2005, at 8:38, Christian Schild wrote: > I don't believe that suppression of (client) DHCPv6 packets is > enforceable. What if the client is not pleased with what he got? Whether something is enforceable is not the point. The IETF can't enforce _anything_, that's a given. What's important is the default behavior. We MUST avoid a situation where hosts do DHCPv6 out of the box regardless of the value of the M and O bits. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 03 04:32:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De7bv-0003tR-I6; Fri, 03 Jun 2005 04:32:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De7bt-0003sN-14; Fri, 03 Jun 2005 04:32: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 EAA04161; Fri, 3 Jun 2005 04:32:55 -0400 (EDT) From: matthew.ford@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De7w4-0006HI-2u; Fri, 03 Jun 2005 04:53:49 -0400 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 09:32:45 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Jun 2005 09:32:45 +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, 3 Jun 2005 09:31:15 +0100 Message-ID: <0AAF93247C75E3408638B965DEE11A700F3C9177@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnFiDL/H0oVNoJSmarjTpBo4NEjwAcLMSwAACyYrAAASHZYAAgB/IA To: , , , X-OriginalArrivalTime: 03 Jun 2005 08:32:45.0425 (UTC) FILETIME=[D0F58E10:01C56816] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Hi Jim, Bound, Jim wrote: > Mat, >=20 >> stateful/stateless is of no concern to the client, right? so if the >> initiator is always the same, then the question of authority becomes >> moot. >=20 > Let me restate I don't think you parsed my question, which > may have been > unclear in hingsight? I think there has been some confusion wrt stateful/stateless address allocation vs. stateful/stateless DHCPv6. > For an IPv6 link the RA informs nodes whether they are permitted to > use stateful, the default preference is stateless, meaning DO NOT USE > DHCPv6 for anything, unless I set a bit that informs you that your > permitted to use stateful on this link. Yes, agreed. Going further, maybe A=3D0 could signal this? > Do you disagree with that the IPv6 Link uses this model. No I don't disagree, I think we are in violent agreement. -- 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 Jun 03 08:58:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBkf-0002nB-GX; Fri, 03 Jun 2005 08:58:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBka-0002l9-DS; Fri, 03 Jun 2005 08:58: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 IAA24293; Fri, 3 Jun 2005 08:58:10 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeC4o-0003MC-N9; Fri, 03 Jun 2005 09:19:07 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id E17C82000188; Fri, 3 Jun 2005 08:57:56 -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, 3 Jun 2005 08:57:56 -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, 3 Jun 2005 08:57:54 -0400 Message-ID: <936A4045C332714F975800409DE092405EBCB6@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVoBtvwNK0SOmYKR/2gzJM24SAyRwAMzuQw From: "Bound, Jim" To: "Christian Schild" X-OriginalArrivalTime: 03 Jun 2005 12:57:56.0708 (UTC) FILETIME=[DCD2AA40:01C5683B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Christian, I can live with a SHOULD (I was using MUST to get folks to respond :--)). I just don't think we can have our cake and eat it too, it is an immature view to try. We also have to realize for any spec implementations will always support what the customer wants in cases of choices over the spec in case of a SHOULD. That makes sense too and the users will cause the correction they want. But, we need to make sure the users "clearly" understand the intent of our IETF work too. The consensus here in the IETF is that statless should be used whereever possible. Note I am not against dhc6 and stateful either I put a part of my IETF lifetime into dhc6 and pushed it all the way back at IETF Danvers 1995. But, I do believe the inherent Steve Deering (Father of IPv6) model of IPv6 permitting stateless behavior is correct view for the evolution of the Internet using IPv6. I don't think we need the O bit anymore either. Leave that to dhc WG and process. But, we need a way to suggest a large code base transition for dropping the O bit for ND and Addcronf. The if conditionals for the M bit should support this without adding a lot of code to implementations is my view, from talking with some other implementers.=20 Also if we can do this quickly it would be good because of updates to 2461biz and 2462biz. =20 Also I agree with you, when no RA it is a free zone decison client can us dhc. But, I don't support putting that text in ND or addrconf as it opens up discussion not currently there. We are silent on this use case and should remain silent. If we want to open this aspect of link behavior it should be its own IETF spec and work item, approved by IPv6 Chairs and this WG. Reason is there is more to this than just dhc clients. thanks /jim > -----Original Message----- > From: Christian Schild [mailto:join@uni-muenster.de]=20 > Sent: Friday, June 03, 2005 2:38 AM > To: Bound, Jim > Cc: dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 > Hi Jim,=20 >=20 > Am Donnerstag, den 02.06.2005, 12:23 -0400 schrieb Bound, Jim: >=20 > > > So you don't believe that the RA in ND should be the authority to > > > use a stateful model on an IPv6 link? >=20 > Thanks for your question, I think that's a key part of the=20 > discussion.=20 >=20 > I know what you are trying to achieve. As a network admin it=20 > is a really > desirable goal to be in control of the clients to send DHCPv6 messages > or not. This control in fact could be achieved with a proper=20 > definition > and usage of the M/O bit(s). >=20 > But: >=20 > > > stateful/stateless is of no concern to the client, right?=20 > so if the > > > initiator is always the same, then the question of=20 > authority becomes > > > moot. > >=20 > > Let me restate I don't think you parsed my question, which=20 > may have been > > unclear in hingsight? > >=20 > > For an IPv6 link the RA informs nodes whether they are=20 > permitted to use > > stateful, the default preference is stateless, meaning DO=20 > NOT USE DHCPv6 > > for anything, unless I set a bit that informs you that your=20 > permitted to > > use stateful on this link. > >=20 > > This means the client after getting A bit set, and M/O bits=20 > not set, and > > prefix list it does not execute DHCPv6 client code at all. > >=20 > > This is what I mean't by authority of RA to the client. > >=20 > > Do you disagree with that the IPv6 Link uses this model. =20 > >=20 > > The way most implementations I am aware of work is as=20 > follows as hosts: > >=20 > > If 'A' bit set with prefixes provided, set prefix=20 > list/lifetimes to on, > > and configure addresses from prefix with EUI. > >=20 > > THEN check: > >=20 > > If 'M' or 'O' bit set then call dhcpv6 client thread, or however > > engnineer wanted to implement this, ELSE dhcpv6 is not called. >=20 > This is the ideal scenario, yes. > (side note: I think we agree, that a client is allowed to do dhcpv6 in > the lack of RAs?) >=20 > I think this scenario might fail, because: > Client (needing addresses and information) and routers=20 > (sending RAs) are > two different entities with their own set of behaviours and their own > set of wishes. In your model you are trying to force the client to do > something what the router wants. Fine with me, but > I don't believe that suppression of (client) DHCPv6 packets is > enforceable. What if the client is not pleased with what he got? >=20 > E.g.: > The client desperately needs an additional information, lets=20 > say an NTP > server. Maybe because an application needs it. The client may get the > idea "ok, I'm not allowed to do DHCPv6, but I really really need that > information" so it will launch DHCPv6. NTP is just an example.=20 >=20 > E.g.: > What if the client is not pleased with the address he got.=20 > E.g. he only=20 > got a ULA prefix via the RA and wants to communicate with the global > network. Then the client may probe if there are more and=20 > better prefixes > available in DHCPv6. This can even get initiated by a user (!). >=20 > I hope you know what I'm trying to say. The really dangerous part in > your model is, that a network administrator may get the=20 > impression, that > now that DHCPv6 is disable on that link (M=3D0,O=3D0), nothing on=20 > that link=20 > will use it. As shown above, this may not be true, it is not > enforceable. >=20 > And my conclusion to this: > If we really want to use the M/O bits, then please make them=20 > just hints. > A SHOULD is good, a MUST is too strong.=20 >=20 > Christian >=20 >=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 Fri Jun 03 09:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBsu-0006Hb-8g; Fri, 03 Jun 2005 09:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBss-0006H4-Ed; Fri, 03 Jun 2005 09:06: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 JAA25176; Fri, 3 Jun 2005 09:06:45 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeCD7-0003bc-9X; Fri, 03 Jun 2005 09:27: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 B334D200019F; Fri, 3 Jun 2005 09:06:37 -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, 3 Jun 2005 09:06:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Jun 2005 09:06:35 -0400 Message-ID: <936A4045C332714F975800409DE092405EBCBF@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnFiDL/H0oVNoJSmarjTpBo4NEjwAcLMSwAACyYrAAASHZYAAgB/IAAAt7x6A= From: "Bound, Jim" To: , , , X-OriginalArrivalTime: 03 Jun 2005 13:06:37.0532 (UTC) FILETIME=[134219C0:01C5683D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Mat,=20 > Yes, agreed. Going further, maybe A=3D0 could signal this? Not bad Mat. That might actually work. Kudos to your logic parsing here. In our fury to make sure we told clients use stateless we added the M bit. O bit was an anomaly IMO. Need to roll this around in my brain with implementer view it will cause some pain to upgrade the code base. And now we are talking about widely deployed code base and actually shipping products that are being used significantly for some pretty important deployments. Sure makes life simpler and gets us two extra bits back. IPv6 ND and Addrcon base spec implementers what do you think? Probably could be done in next OS upgrade not that much code change? 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 Jun 03 12:41:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFEK-00053P-EG; Fri, 03 Jun 2005 12:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFEI-00052V-LG; Fri, 03 Jun 2005 12:41: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 MAA13142; Fri, 3 Jun 2005 12:41:04 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeFYV-0008Un-1S; Fri, 03 Jun 2005 13:02:03 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA27967; Fri, 3 Jun 2005 11:40:47 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j53Gekn25120; Fri, 3 Jun 2005 09:40:46 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 09:40:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Jun 2005 09:40:46 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4E95@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVnvov0pm+k/tCmS3eET6Nf/U2JWQAMUcPgABqS8tA= From: "Templin, Fred L" To: "Bound, Jim" , "Christian Schild" , , X-OriginalArrivalTime: 03 Jun 2005 16:40:46.0552 (UTC) FILETIME=[FDDEF580:01C5685A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Thanks for the response Jim, and not looking to cause ratholes. Not sure = on all points, but I agree that we should not be trying to legislate (or = anticipate) policies in any mechanisms we specify. There was also a wording gaffe in the phrase: "one question I had"; the = intent was not to satisfy the author's personal curiosity but rather to = explore the underlying assumptions for the benefit of the list. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Bound, Jim [mailto:jim.bound@hp.com] > Sent: Thursday, June 02, 2005 9:04 PM > To: Templin, Fred L; Christian Schild; dhcwg@ietf.org; ipv6@ietf.org > Subject: RE: [dhcwg] RE: purpose of m/o bit >=20 >=20 > Fred, >=20 > Good questions. But could cause gigantic rat-hole :--) >=20 > > At the risk of covering old ground, one question I had is=20 > > whether a client must wait to receive an RA before initiating=20 > > stateless or stateful DHCPv6? Asked another way, can DHCPv6=20 > > still be used if there are no advertising routers on the link? >=20 > To get prefixes yes, and to use them the A bit should be set.=20 > But IPv6 > is stateless in the node. The node creates the link-local=20 > and then DAD > on the network. Though I think shutting DAD off completely in some > environments is now prudent for some users special networks. =20 >=20 > >=20 > > To an even more speculative question, if we had it all to do=20 > > over again would it be possible (or desireable) to design=20 > > things such that DHCPv6 and IPv6 ND messages could be=20 > > "piggybacked" within a single packet? (This begs the question=20 > > of whether the DHCPv6 server/relay and IPv6 router entities=20 > > are co-resident on the same node in the normal case.) >=20 > Two questions really. >=20 > On piggy-back I don't think so for me. Stateless is the win=20 > for IP from > the efforts for IPv6, and permeates its technical and operational > benefits for networks, DHCP is stateful and means some server function > exists that has state. I support the model now and the=20 > authority plane > of stateless or stateful model via the A bit and then stating=20 > to use or > not use stateful. >=20 > As far as co-locating the functions that is an implementation=20 > choice and > we should not speculate on implementation of that nature=20 > between routers > vs. hosts. vs. servers. vs clients, when building a standard on this > topic. Also can start an anti-trust problem :--). So I say let the > market decide on that one. I don't think its a good idea personally > speaking strictly as individual knowing both routers and hosts as IP > stack architecture and their purpose in my view. >=20 > I think its pretty simple and backwards compatibility for ND and > addrconf is drop the o bit and keep the m bit see my previous=20 > suggestion > on this sent a day or so ago. >=20 > thanks > /jim > =20 > >=20 > > Fred > > fred.l.templin@boeing.com =20 > >=20 > > "Bound, Jim" wrote: > > > > It would be really nice and handy to initiate either=20 > 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=20 > > simply initiate > > > > a(n Information) Request message and would get all the=20 > information > > > > that are available on the link, including an address or not. > > > > > > So you don't believe that the RA in ND should be the=20 > > authority to use a > > > stateful model on an IPv6 link? > > > > > > /jim > >=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 Fri Jun 03 13:21:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFrH-0004Nx-W7; Fri, 03 Jun 2005 13:21:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeFrF-0004NQ-Nu; Fri, 03 Jun 2005 13:21: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 NAA15837; Fri, 3 Jun 2005 13:21:18 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeGBV-0000sC-D2; Fri, 03 Jun 2005 13:42:19 -0400 Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j53HLCau018466; Fri, 3 Jun 2005 11:21:12 -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 j53HLBWR838831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 3 Jun 2005 10:21:12 -0700 (PDT) Message-ID: <42A0919A.3010302@sun.com> Date: Fri, 03 Jun 2005 10:21: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: matthew.ford@bt.com References: <0AAF93247C75E3408638B965DEE11A700F3C9177@i2km41-ukdy.domain1.systemhost.net> In-Reply-To: <0AAF93247C75E3408638B965DEE11A700F3C9177@i2km41-ukdy.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, ipv6@ietf.org, jim.bound@hp.com 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 matthew.ford@bt.com wrote: > Yes, agreed. Going further, maybe A=0 could signal this? But the A flag is per prefix, not per RA. And so far we haven't assigned any semantics to a flag in the prefix being zero; the semantics are associated with the flags being set to one. That model seems to be useful when extending the flags in the prefixes since it provide orthogonal flags. For instance, we added the 'R' flag and with that we can have Prefix option which set only the R flag (as well as the R flag in combination with one of A and L) and the addrconf and on-link pieces don't get confused by a prefix with R=1, A=0, L=0; those functions just ignore prefixes that have A=0 and L=0, respectively. 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 Jun 03 19:06:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLEw-0003N9-AR; Fri, 03 Jun 2005 19:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLEt-0003Jk-Dg for ipv6@megatron.ietf.org; Fri, 03 Jun 2005 19:06: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 TAA23062 for ; Fri, 3 Jun 2005 19:06:04 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeLZD-000447-9n for ipv6@ietf.org; Fri, 03 Jun 2005 19:27:07 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j53N5vGH014015; Fri, 3 Jun 2005 18:05:57 -0500 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Fri, 3 Jun 2005 18:01:13 -0500 Received: from [142.133.72.115] (dhcp723-115.rnet.lmc.ericsson.se [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MFNRGDY4; Fri, 3 Jun 2005 19:05:45 -0400 Message-ID: <42A0E1F8.5090204@ericsson.ca> Date: Fri, 03 Jun 2005 19:04:24 -0400 From: Suresh Krishnan Organization: Ericsson User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: timbeck04@verizon.net References: <23049152.1117728092907.JavaMail.root@vms062.mailsrvcs.net> In-Reply-To: <23049152.1117728092907.JavaMail.root@vms062.mailsrvcs.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-privacy-addrs-v2-04 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: suresh.krishnan@ericsson.ca List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Tim, Thanks for the comments. Please see my replies inline. Cheers Suresh timbeck04@verizon.net wrote: > Good morning all. I'm aware this draft is in AD Review/AD Follow-up > status, and hope this is an appropriate time to raise questions (none > being rhetorical) and issues. I'd greatly appreciate technical group > feedback on the following: > > ___ > > In section 3, it is stated 'Deprecated addresses can continue to be used > for already established connections...'. In section 3.6 it is stated > '... some applications may not behave robustly if temporary addresses > are used and an address expires before the application has terminated, > or if it opens multiple sessions but expects them all to use the same > addresses.' > > It seems to me that given section 3., the only times when the section > 3.6 statement would likely be true is if a session is terminated, then a > new one is established. Section 3.6 deals with deployment considerations. The statement you quoted is just a warning for implementers to disable use of temporary addresses when the applications may not handle them properly. "In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions." So, in summary, section 3 specifies that WHEN temporary addresses ARE BEING USED, what should be the behaviour of the system when the preferred lifetime expires Section 3.6 recommends DISABLING temporary addresses if there is a high probability of some applications misbehaving because of enabling them. Does that answer your question? If not, please let me know and maybe we can work on some text. > > ___ > > In section 3.5, it is stated 'The value DESYNC_FACTOR is a random value > (different for each client) that ensures that clients don't synchronize > with each other and generate new addresses at exactly the same time.' > > How do we really know if DESYNC_VALUE will be different for each client? > The answer doesn't seem to be in this draft. > > Presuming DESYNC_VALUE to be an integer (0=lower bound, 600 > seconds=MAX_DESYNC_FACTOR=upper bound), there would only be 601 possible > values. Thus it seems to me the random number generator used to > determine this value is fairly limited. The granularity of DESYNC_FACTOR is not mandated by the draft. If you feel that 600 unique values are not sufficient, you can use a DESYNC_FACTOR with millisecond accuracy thus giving you 600000 unique values. > > ___ > > Including in section 5., regarding both the TEMP_VALID_LIFETIME and the > TEMP_PREFERRED_LIFETIME values: 'Users should be able to override the > default value.' Is the network administrator able to override values set > by users? It seems to me administrators should have that ability. Actually it was meant to be used the other way. The network admins set the default value and the users can override it if their applications need different values. If you think admins should have absolute control, you don't have to allow users to override these values (that is why the requirement is SHOULD and not MUST) and still be compliant to the specification. > > ___ > > Best regards, > > Tim Enos > 1Sam16: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 Sat Jun 04 01:30:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeREx-0001Ty-4p; Sat, 04 Jun 2005 01:30:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeREs-0001TR-GA; Sat, 04 Jun 2005 01:30: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 BAA14468; Sat, 4 Jun 2005 01:30:29 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeRZE-0002vb-GQ; Sat, 04 Jun 2005 01:51:33 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 3E70A118; Sat, 4 Jun 2005 01:27: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); Sat, 4 Jun 2005 01:30:15 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 4 Jun 2005 01:30:13 -0400 Message-ID: <936A4045C332714F975800409DE092405EC013@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVoYKqkQB/KVmbxQC2eSLdcCS+rvwAZWXgQ From: "Bound, Jim" To: "Erik Nordmark" , X-OriginalArrivalTime: 04 Jun 2005 05:30:15.0872 (UTC) FILETIME=[7CEE1C00:01C568C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 But it is possible to change the meaning of A=3D0 to mean use dhc if you have it. Also multiple prefixes can be provided.=20 L and A are orthogonal. If you set L and not A all that was stated is use these for link knowlege but not for autoconfigure. /jim=20 > -----Original Message----- > From: Erik Nordmark [mailto:erik.nordmark@sun.com]=20 > Sent: Friday, June 03, 2005 1:22 PM > To: matthew.ford@bt.com > Cc: Bound, Jim; join@uni-muenster.de; dhcwg@ietf.org; ipv6@ietf.org > Subject: Re: [dhcwg] RE: purpose of m/o bit >=20 > matthew.ford@bt.com wrote: >=20 > > Yes, agreed. Going further, maybe A=3D0 could signal this? >=20 > But the A flag is per prefix, not per RA. > And so far we haven't assigned any semantics to a flag in the prefix=20 > being zero; the semantics are associated with the flags being=20 > set to one. > That model seems to be useful when extending the flags in the=20 > prefixes=20 > since it provide orthogonal flags. For instance, we added the=20 > 'R' flag=20 > and with that we can have Prefix option which set only the R flag (as=20 > well as the R flag in combination with one of A and L) and=20 > the addrconf=20 > and on-link pieces don't get confused by a prefix with R=3D1, A=3D0, = L=3D0;=20 > those functions just ignore prefixes that have A=3D0 and L=3D0,=20 > respectively. >=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 Sat Jun 04 05:14:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeUjy-0004OW-6X; Sat, 04 Jun 2005 05:14:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeUjw-0004OO-En; Sat, 04 Jun 2005 05:14: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 FAA17455; Sat, 4 Jun 2005 05:14:46 -0400 (EDT) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeV4L-0007Bg-Rw; Sat, 04 Jun 2005 05:35:54 -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 j549EYTJ058267 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 4 Jun 2005 11:14:35 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <936A4045C332714F975800409DE092405EC013@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092405EC013@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: <2D2EBF97-AAF4-43D1-B4CF-B09B7A5CD4E5@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Sat, 4 Jun 2005 11:14:29 +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: de4f315c9369b71d7dd5909b42224370 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 4-jun-2005, at 7:30, Bound, Jim wrote: > But it is possible to change the meaning of A=0 to mean use dhc Sure. > if you have it. But not that part. If the autonomous address configuration flag is zero for all prefixes in an RA, a host not implementing DHCPv6 is dead in the water. (Some implemtations, such as KAME, don't properly fall back on IPv4 when they don't have any IPv6 addresses but do have an IPv6 default route because there are RAs.) What exactly is the problem we're trying to solve here? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jun 05 00:00:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DemJK-0000xS-Qi; Sun, 05 Jun 2005 00:00:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DemJJ-0000xK-6e for ipv6@megatron.ietf.org; Sun, 05 Jun 2005 00:00: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 AAA18426 for ; Sun, 5 Jun 2005 00:00:26 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Demds-00020p-Cf for ipv6@ietf.org; Sun, 05 Jun 2005 00:21:44 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id D74F1156 for ; Sun, 5 Jun 2005 00:00:16 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 05 Jun 2005 00:00:16 -0400 Message-Id: <20050605040016.D74F1156@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 --------+------+--------+----------+------------------------ 12.68% | 9 | 12.30% | 43291 | jim.bound@hp.com 12.68% | 9 | 12.15% | 42788 | iljitsch@muada.com 5.63% | 4 | 6.06% | 21339 | h.soliman@flarion.com 5.63% | 4 | 5.19% | 18274 | sebastien.roy@sun.com 5.63% | 4 | 4.38% | 15407 | matthew.ford@bt.com 4.23% | 3 | 4.94% | 17399 | join@uni-muenster.de 4.23% | 3 | 4.72% | 16632 | jinmei@isl.rdc.toshiba.co.jp 2.82% | 2 | 5.99% | 21098 | chvogt@tm.uka.de 4.23% | 3 | 4.43% | 15612 | greg.daley@eng.monash.edu.au 4.23% | 3 | 3.75% | 13200 | soohong.park@samsung.com 4.23% | 3 | 3.17% | 11161 | pekkas@netcore.fi 2.82% | 2 | 3.24% | 11409 | sharkey@zoic.org 2.82% | 2 | 3.22% | 11325 | fred.l.templin@boeing.com 2.82% | 2 | 2.77% | 9765 | dsmalls321@yahoo.com 2.82% | 2 | 2.60% | 9165 | timbeck04@verizon.net 2.82% | 2 | 2.48% | 8742 | rdroms@cisco.com 2.82% | 2 | 2.46% | 8671 | iesg-secretary@ietf.org 1.41% | 1 | 2.27% | 7993 | brian@innovationslab.net 1.41% | 1 | 1.98% | 6963 | suresh.krishnan@ericsson.ca 1.41% | 1 | 1.42% | 4984 | volz@cisco.com 1.41% | 1 | 1.36% | 4774 | sra+ipng@hactrn.net 1.41% | 1 | 1.28% | 4523 | dthaler@windows.microsoft.com 1.41% | 1 | 1.22% | 4286 | mohacsi@niif.hu 1.41% | 1 | 1.20% | 4241 | tjc@ecs.soton.ac.uk 1.41% | 1 | 1.16% | 4068 | kempf@docomolabs-usa.com 1.41% | 1 | 1.13% | 3992 | tim@mentat.com 1.41% | 1 | 1.06% | 3740 | erik.nordmark@sun.com 1.41% | 1 | 1.03% | 3614 | rkrishnan.s@samsung.com 1.41% | 1 | 1.03% | 3614 | mailman-owner@ietf.org --------+------+--------+----------+------------------------ 100.00% | 71 |100.00% | 352070 | 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 Jun 06 02:17:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfAvr-0005YN-QO; Mon, 06 Jun 2005 02:17:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfAvp-0005YI-8Y for ipv6@megatron.ietf.org; Mon, 06 Jun 2005 02:17: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 CAA22579 for ; Mon, 6 Jun 2005 02:17:49 -0400 (EDT) Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfBGF-0000Ss-W2 for ipv6@ietf.org; Mon, 06 Jun 2005 02:39:20 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id E883114333; Mon, 6 Jun 2005 02:17:27 -0400 (EDT) Received: from [127.0.0.1] ([16.123.208.245]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id LAA09200; Mon, 6 Jun 2005 11:45:13 +0530 (IST) Message-ID: <42A3EA62.40105@india.hp.com> Date: Sun, 05 Jun 2005 23:17:06 -0700 From: Arun Thulasi User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas References: <4283CEA2.7000402@india.hp.com> <20050513175356.GB24255@storhaugen.uninett.no> In-Reply-To: <20050513175356.GB24255@storhaugen.uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Arun T 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 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 Hello Stig, Bear with me for the delayed reply. Do look inline for my reply to your comments and suggestions. >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 did a run through of the ssm and allied drafts. The behavior that we have suggested in the draft is independent of SSM. By this I suggest that if the user wants to implement SSM, it would have to involve some kind of filtering. Since SSM requires a (S,G) format where there has to be exactly one source and multiple receivers (as specified in the document), it is different from the default behavior what we propose in our draft which applies for ordinary multicasting scenarios. However, it would be a better idea to include something on SSM support in the document (the least is to mention that SSM is not part of the scenario and atmost explain what differentiates this solution from the SSM scenario) since this document talks about multicast filtering rules in IPv6. If the general consensus is that, i can work on including that. >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. > > > Yes. This is indeed SSM specific (when you want to exclude sources etc). One way to include SSM in the draft is to talk about all this in the filtering scenario, still suggesting that this is optional and not default behavior. >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. > > > I think this is what we present in the draft. If another application binds to the right port and wild card address, it would still be delivered the packet. In my opinion, i guess it could be a good idea to talk about SSM in the draft, in the filtering behavior section. I can even work on a separate section that talks about Multicast Filtering in SSM based scenarios. Do let me know what you suggest. Thanks, Arun T >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 Jun 06 10:43:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIol-0002m7-K4; Mon, 06 Jun 2005 10:43:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIoi-0002m1-VV for ipv6@megatron.ietf.org; Mon, 06 Jun 2005 10:43: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 KAA06872 for ; Mon, 6 Jun 2005 10:43:00 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfJ9E-0002a8-Ig for ipv6@ietf.org; Mon, 06 Jun 2005 11:04:37 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 895BA41427D; Sun, 5 Jun 2005 23:17:39 -0700 (PDT) Received: from [127.0.0.1] ([16.123.208.245]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id LAA09246; Mon, 6 Jun 2005 11:45:25 +0530 (IST) Message-ID: <42A3EA7B.4030905@india.hp.com> Date: Sun, 05 Jun 2005 23:17:31 -0700 From: Arun Thulasi User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hoerdt Mickael References: <4283CEA2.7000402@india.hp.com> <4284F189.2030601@clarinet.u-strasbg.fr> In-Reply-To: <4284F189.2030601@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable 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 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 Hello Hoerdt, Do bear with me for the delayed reply. Do find my reply to you inline. >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... > > =20 > I ran some tests on a few implementations. I did see them behaving=20 differently while receving multicast packets destined to certain=20 addresses. We had actually formed the idea of a draft specifying the=20 rules for multicast filtering only after noticing that. >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". > > =20 > Agreed. However, i would prefer to have the word "applications" in the=20 text, but still add "sockets" to differentiate between the two entities=20 and putting the forth the point of them being some sort of a interface=20 handle. Do let me know of your suggestions of how else we can=20 differentiate between these two entities. >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. > > =20 > RFC1112 talks how the all-host group is a special case and always starts=20 as an Idle Member and never transitions to another state. I reckon this=20 would suggest that the address should be ON all the time. I would be working on including new filtering rules when SSM is present=20 on the machine. Do let me know if you would require the draft to address=20 any more issues. Cheers, Arun T >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 > =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 Jun 06 13:42:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLcI-0000Gb-LN; Mon, 06 Jun 2005 13:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLcG-0000Fw-OU; Mon, 06 Jun 2005 13:42: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 NAA21120; Mon, 6 Jun 2005 13:42:23 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfLx8-0006iB-RE; Mon, 06 Jun 2005 14:04:00 -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 j56HgFn0022057; Mon, 6 Jun 2005 11:42:15 -0600 (MDT) Received: from [129.146.228.82] (par.SFBay.Sun.COM [129.146.228.82]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j56Hg8nQ412654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2005 10:42:14 -0700 (PDT) Message-ID: <42A48AE7.2030701@sun.com> Date: Mon, 06 Jun 2005 10:41:59 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" References: <936A4045C332714F975800409DE092405EC013@tayexc14.americas.cpqcorp.net> In-Reply-To: <936A4045C332714F975800409DE092405EC013@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, dhcwg@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 Bound, Jim wrote: > But it is possible to change the meaning of A=0 to mean use dhc if you have > it. > > Also multiple prefixes can be provided. > > L and A are orthogonal. If you set L and not A all that was stated is use > these for link knowlege but not for autoconfigure. But the fact that the A flag appears in every Prefix information option makes defining the semantics of A=0 as "use DHC" quite tricky. Suppose the RA contains 2 PIOs: prefix1, A=1, O=1, R=0 prefix2. A=0, O=0, R=1 (The R flag was defined in the Mobile IPv6 RFC) Should this mean "use DHC" or not? What if some future RFC introduces an additional flag in the Prefix information option (as Mobile IPv6 just did); what's the semantics of A=0, O=0, R=0, New flag=1 in terms of DHC? Does the semantics change whether or not there are other prefixes included in the RA. Thus defining the semantics of the M/O bits in the RA is trivial compared to trying to overload A=0! Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 06 19:47:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfRJz-0005Ms-Mu; Mon, 06 Jun 2005 19:47:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfRJx-0005Mf-EM; Mon, 06 Jun 2005 19:47: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 TAA01412; Mon, 6 Jun 2005 19:47:50 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfRet-0001eb-Su; Mon, 06 Jun 2005 20:09:32 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j56NkSL04603; Mon, 6 Jun 2005 16:46:28 -0700 (PDT) Message-Id: <200506062346.j56NkSL04603@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 06 Jun 2005 16:46:28 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4087 on IP Tunnel MIB X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Request for Comments is now available in online RFC libraries. RFC 4087 Title: IP Tunnel MIB Author(s): D. Thaler Status: Standards Track Date: June 2005 Mailbox: dthaler@microsoft.com Pages: 25 Characters: 53206 Obsoletes: 2667 I-D Tag: draft-ietf-ipv6-inet-tunnel-mib-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4087.txt This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050606164525.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4087 --OtherAccess Content-Type: Message/External-body; name="rfc4087.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050606164525.RFC@RFC-EDITOR.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 Jun 06 20:00:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfRWB-0001uH-Oo; Mon, 06 Jun 2005 20:00:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfRW9-0001lU-3P; Mon, 06 Jun 2005 20:00: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 UAA04491; Mon, 6 Jun 2005 20:00:27 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfRr1-0002fL-If; Mon, 06 Jun 2005 20:22:06 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id C61A213C; Mon, 6 Jun 2005 20:00:10 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 19:59:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 6 Jun 2005 19:59:00 -0400 Message-ID: <936A4045C332714F975800409DE092405EC420@tayexc14.americas.cpqcorp.net> Thread-Topic: [dhcwg] RE: purpose of m/o bit Thread-Index: AcVqvyCiLx7XvQv1StCDlQt2sZlJoQANGrfA From: "Bound, Jim" To: "Erik Nordmark" X-OriginalArrivalTime: 06 Jun 2005 23:59:01.0336 (UTC) FILETIME=[B605D580:01C56AF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, dhcwg@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 =20 > Bound, Jim wrote: > > But it is possible to change the meaning of A=3D0 to mean use=20 > dhc if you have > > it. > >=20 > > Also multiple prefixes can be provided.=20 > >=20 > > L and A are orthogonal. If you set L and not A all that was=20 > stated is use > > these for link knowlege but not for autoconfigure. >=20 > But the fact that the A flag appears in every Prefix=20 > information option=20 > makes defining the semantics of A=3D0 as "use DHC" quite tricky. >=20 > Suppose the RA contains 2 PIOs: > prefix1, A=3D1, O=3D1, R=3D0 > prefix2. A=3D0, O=3D0, R=3D1 > (The R flag was defined in the Mobile IPv6 RFC) >=20 > Should this mean "use DHC" or not? >=20 > What if some future RFC introduces an additional flag in the Prefix=20 > information option (as Mobile IPv6 just did); what's the semantics of > A=3D0, O=3D0, R=3D0, New flag=3D1 > in terms of DHC? Does the semantics change whether or not there are=20 > other prefixes included in the RA. >=20 > Thus defining the semantics of the M/O bits in the RA is trivial=20 > compared to trying to overload A=3D0! Agreed the overload as you state would be very tricky and I agree it is probably not worth it to pursue. thanks /jim >=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 Mon Jun 06 20:55:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfSNX-0008OI-Pu; Mon, 06 Jun 2005 20:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfSNW-0008OD-8t for ipv6@megatron.ietf.org; Mon, 06 Jun 2005 20:55: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 UAA10892 for ; Mon, 6 Jun 2005 20:55:36 -0400 (EDT) Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfSiT-0004k0-8k for ipv6@ietf.org; Mon, 06 Jun 2005 21:17:17 -0400 Received: from S018431 ([151.203.51.47]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IHO00CJ4VWNJ9K2@vms044.mailsrvcs.net> for ipv6@ietf.org; Mon, 06 Jun 2005 19:55:36 -0500 (CDT) Date: Mon, 06 Jun 2005 20:55:32 -0400 From: "timothy enos" In-reply-to: <42A0E1F8.5090204@ericsson.ca> To: Message-id: <000d01c56afb$9bf753a0$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: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-privacy-addrs-v2-04 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, Thank you also for your reply! My apologies for not having sent mine sooner; please see inline: Best regards, Tim 1Sam16:7 -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.ca] Sent: Friday, June 03, 2005 7:04 PM To: timbeck04@verizon.net Cc: ipv6@ietf.org Subject: Re: draft-ietf-ipv6-privacy-addrs-v2-04 Hi Tim, Thanks for the comments. Please see my replies inline. Cheers Suresh >> timbeck04@verizon.net wrote: >> Good morning all. I'm aware this draft is in AD Review/AD Follow-up >> status, and hope this is an appropriate time to raise questions (none >> being rhetorical) and issues. I'd greatly appreciate technical group >> feedback on the following: >> >> ___ >> >> In section 3, it is stated 'Deprecated addresses can continue to be used >> for already established connections...'. In section 3.6 it is stated >> '... some applications may not behave robustly if temporary addresses >> are used and an address expires before the application has terminated, >> or if it opens multiple sessions but expects them all to use the same >> addresses.' >> >> It seems to me that given section 3., the only times when the section >> 3.6 statement would likely be true is if a session is terminated, then a >> new one is established. > Section 3.6 deals with deployment considerations. The statement you > quoted is just a warning for implementers to disable use of temporary > addresses when the applications may not handle them properly. OK. It's just that in the first instance (wherein a temp address expires before the application has terminated), it still isn't clear to me why the application would not handle that properly. When would it ever be the case? I suppose an app could be written so that it would terminate any sessions that are using addresses that become deprecated. My thinking is that it would be better for them to continue to be used. Termination of the session could be achieved either by user/admin intervention, or by the expiration of some other timer (e.g. idle timeout). Again not rhetorical; I truly do not know the answer. In the second instance, are you referring to an application residing on one host (call it node A) opening multiple sessions with one other host (node B), or more than one host (B, C, ...)? >> "In addition, some applications may not behave >> robustly if temporary addresses are used and an address expires >> before the application has terminated, or if it opens multiple >> sessions, but expects them to all use the same addresses. >> Consequently, the use of temporary addresses SHOULD be disabled by >> default in order to minimize potential disruptions." > So, in summary, section 3 specifies that WHEN temporary addresses ARE > BEING USED, what should be the behaviour of the system when the > preferred lifetime expires > Section 3.6 recommends DISABLING temporary addresses if there is a high > probability of some applications misbehaving because of enabling them. > Does that answer your question? If not, please let me know and maybe we > can work on some text. If possible, I'd like to work on some text (though not a deal breaker if we do not). >> ___ >> >> In section 3.5, it is stated 'The value DESYNC_FACTOR is a random value >> (different for each client) that ensures that clients don't synchronize >> with each other and generate new addresses at exactly the same time.' >> >> How do we really know if DESYNC_VALUE will be different for each client? >> The answer doesn't seem to be in this draft. >> >> Presuming DESYNC_VALUE to be an integer (0=lower bound, 600 >> seconds=MAX_DESYNC_FACTOR=upper bound), there would only be 601 possible >> values. Thus it seems to me the random number generator used to >> determine this value is fairly limited. > The granularity of DESYNC_FACTOR is not mandated by the draft. If you > feel that 600 unique values are not sufficient, you can use a > DESYNC_FACTOR with millisecond accuracy thus giving you 600000 unique > values. Ceteris paribus, it seems that having three orders of magnitude more potential values from which to choose increases our odds of getting the desired results (nodes generating different values). Not required, but potentially helpful (and can't imagine it harmful) to explicitly state that no particular granularity is mandated. >> ___ >> >> Including in section 5., regarding both the TEMP_VALID_LIFETIME and the >> TEMP_PREFERRED_LIFETIME values: 'Users should be able to override the >> default value.' Is the network administrator able to override values set >> by users? It seems to me administrators should have that ability. > Actually it was meant to be used the other way. The network admins set > the default value and the users can override it if their applications > need different values. If you think admins should have absolute control, > you don't have to allow users to override these values (that is why > the requirement is SHOULD and not MUST) and still be compliant to the > specification. IMO, even the SHOULD is a bit too strong. While not advocating for a MUST NOT, I would advocate for a MAY. >> ___ >> >> Best regards, >> >> Tim Enos >> 1Sam16: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 Wed Jun 08 18:58:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg9V6-0002au-UN; Wed, 08 Jun 2005 18:58:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg9V4-0002Yu-Qa for ipv6@megatron.ietf.org; Wed, 08 Jun 2005 18:58: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 SAA27915 for ; Wed, 8 Jun 2005 18:58:15 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg9pu-0005rU-2D for ipv6@ietf.org; Wed, 08 Jun 2005 19:19:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j58MPKR07662; Wed, 8 Jun 2005 15:25:20 -0700 X-mProtect: <200506082225> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp16061.americas.nokia.com (10.241.160.61, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpda7CLGk; Wed, 08 Jun 2005 15:25:18 PDT Message-Id: <6.2.1.2.2.20050608155530.02b289e0@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 08 Jun 2005 15:56:59 -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: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Last Call: 'BGP-MPLS VPN extension for IPv6 VPN' 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. Please review and send comments to iesg@ietf.org or ietf@ietf.org mailing lists by 2005-06-22. Thanks, Bob >Subject: Last Call: 'BGP-MPLS VPN extension for IPv6 VPN' to >Proposed Standard >Date: Wed, 08 Jun 2005 17:43:39 -0400 >From: The IESG >Reply-To: iesg@ietf.org >To: IETF-Announce >CC: l3vpn@ietf.org > >The IESG has received a request from the Layer 3 Virtual Private Networks WG >to consider the following document: > >- 'BGP-MPLS VPN extension for IPv6 VPN ' > 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-06-22. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-06.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 Fri Jun 10 13:33:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgnNY-0005x7-39; Fri, 10 Jun 2005 13:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgnNW-0005wz-AH; Fri, 10 Jun 2005 13:33:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13222; Fri, 10 Jun 2005 13:33:08 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgnjE-0004SJ-69; Fri, 10 Jun 2005 13:55:36 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j5AHWcL29641; Fri, 10 Jun 2005 10:32:38 -0700 (PDT) Message-Id: <200506101732.j5AHWcL29641@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 10 Jun 2005 10:32:38 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4113 on Management Information Base for the User Datagram Protocol (UDP) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 Request for Comments is now available in online RFC libraries. RFC 4113 Title: Management Information Base for the User Datagram Protocol (UDP) Author(s): B. Fenner, J. Flick Status: Standards Track Date: June 2005 Mailbox: fenner@research.att.com, john.flick@hp.com Pages: 19 Characters: 40323 Obsoletes: 2454, 2013 I-D Tag: draft-ietf-ipv6-rfc2013-update-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4113.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. This document is a product of the IP Version 6 Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050610103125.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4113 --OtherAccess Content-Type: Message/External-body; name="rfc4113.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050610103125.RFC@RFC-EDITOR.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 Sun Jun 12 00:00:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhJeS-0005bj-SV; Sun, 12 Jun 2005 00:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhJeQ-0005aw-H6 for ipv6@megatron.ietf.org; Sun, 12 Jun 2005 00:00:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02647 for ; Sun, 12 Jun 2005 00:00:43 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhK0N-0008Of-L3 for ipv6@ietf.org; Sun, 12 Jun 2005 00:23:30 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 08C6D119 for ; Sun, 12 Jun 2005 00:00:18 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 12 Jun 2005 00:00:18 -0400 Message-Id: <20050612040018.08C6D119@cyteen.hactrn.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 22.22% | 2 | 26.19% | 13065 | rfc-editor@rfc-editor.org 22.22% | 2 | 23.31% | 11628 | arunt@india.hp.com 11.11% | 1 | 16.79% | 8373 | timbeck04@verizon.net 11.11% | 1 | 9.44% | 4706 | sra+ipng@hactrn.net 11.11% | 1 | 8.50% | 4238 | jim.bound@hp.com 11.11% | 1 | 7.95% | 3963 | erik.nordmark@sun.com 11.11% | 1 | 7.83% | 3905 | bob.hinden@nokia.com --------+------+--------+----------+------------------------ 100.00% | 9 |100.00% | 49878 | 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 Jun 12 05:06:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhOPx-0007bh-Tp; Sun, 12 Jun 2005 05:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhOPw-0007bX-HF for ipv6@megatron.ietf.org; Sun, 12 Jun 2005 05:06:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19414 for ; Sun, 12 Jun 2005 05:06:05 -0400 (EDT) Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhOlw-0000gl-RR for ipv6@ietf.org; Sun, 12 Jun 2005 05:28:55 -0400 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id j5C95nuT051858; Sun, 12 Jun 2005 18:05:49 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Sun, 12 Jun 2005 18:00:39 +0900 (JST) Message-Id: <20050612.180039.846932557.fujisaki@syce.net> To: ipv6@ietf.org From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: Address selection policy distribution X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 submitted a draft about IPv6 address selection policy distribution. This draft is revised version of the draft `Source Address Selection Policy option for DHCPv6', that I proposed at last dhc wg meeting. I need inputs from IPv6 wg to this DHCPv6 option. Title: Distributing Default Address Selection Policy using DHCPv6 Filename: draft-fujisaki-dhc-addr-select-opt-00.txt The previous draft was targeted only for distributing the source address selection policy, but based on the discussion at last dhc wg meeting, I rewrote the draft to allow to distribute the full address selection policy table described in RFC3484. With this option, it is possible to configure nodes' default address selection behavior. Examples are described in the RFC3484 section 10 (Actually, we wrote a practical usage draft of this option, but it became almost same as RFC3484 section 10). I highly appreciate if you give us any suggestions or comments on our drafts. Yours sincerely, -- Tomohiro Fujisaki -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 15 16:15:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DieHK-0004oP-5c; Wed, 15 Jun 2005 16:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DieGT-0004Qd-Fd; Wed, 15 Jun 2005 16:13:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23006; Wed, 15 Jun 2005 16:13:31 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiedD-0008Li-C8; Wed, 15 Jun 2005 16:37:03 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DieGN-0006vE-5R; Wed, 15 Jun 2005 16:13:27 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Jun 2005 16:13:27 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-over-ppp-v2-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 : IP Version 6 over PPP Author(s) : S. Varada, et al. Filename : draft-ietf-ipv6-over-ppp-v2-02.txt Pages : 15 Date : 2005-6-15 The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP and the method for forming IPv6 link-local addresses on PPP links. It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration. This document is an update to RFC 2472 and, hence, obsoletes it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-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-over-ppp-v2-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-over-ppp-v2-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-6-15153806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-over-ppp-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-15153806.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 Jun 16 19:02:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3Ne-0006SD-IB; Thu, 16 Jun 2005 19:02:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3Nc-0006S5-ST for ipv6@megatron.ietf.org; Thu, 16 Jun 2005 19:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24391 for ; Thu, 16 Jun 2005 19:02:30 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3kb-0005iz-1X for ipv6@ietf.org; Thu, 16 Jun 2005 19:26:22 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 39F9415218 for ; Fri, 17 Jun 2005 08:06:04 +0900 (JST) Date: Fri, 17 Jun 2005 08:02:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@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: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 should be way too delayed for ipv6-addr-arch-v4 (already approved by the IESG), but... I happen to find one possible clarification which could have been in the latest address architecture document. In a previous discussion back in 2002, we seem to have agreed the loopback interface does not have to have a link-local address (with the "fe80::/10" prefix): http://www.atm.tut.fi/list-archive/ipng/msg02583.html ...despite the requirement in Section 2.1 of draft-ietf-ipv6-addr-arch-v4-04.txt: All interfaces are required to have at least one link-local unicast address (see Section 2.8 for additional required addresses). (this should be generally interpreted that even the loopback interface are required to have at least one fe80::xxx address) It would be great if this clarification could be incorporated into the forthcoming RFC in the editorial stage, but I'm afraid this is beyond a purely editorial change. (And if so, I won't push it. We'll simply wait for the time when we work on addr-arch-v5...) 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 Jun 16 19:56:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj4ED-0000wQ-Gf; Thu, 16 Jun 2005 19:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj4EB-0000wL-8V for ipv6@megatron.ietf.org; Thu, 16 Jun 2005 19:56:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27784 for ; Thu, 16 Jun 2005 19:56:50 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj4b9-00006a-Rv for ipv6@ietf.org; Thu, 16 Jun 2005 20:20:41 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5GNOLa22397; Thu, 16 Jun 2005 16:24:21 -0700 X-mProtect: <200506162324> Nokia Silicon Valley Messaging Protection Received: from danira-pool048180.americas.nokia.com (10.241.48.180, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdFOsbav; Thu, 16 Jun 2005 16:24:20 PDT Message-Id: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 16 Jun 2005 16:56:27 -0700 To: =?iso-2022-jp?Q?ext_JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= From: Bob Hinden In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ipv6@ietf.org Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, At 04:02 PM 06/16/2005, =?iso-2022-jp?Q?ext_JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1 wrote: >This should be way too delayed for ipv6-addr-arch-v4 (already approved >by the IESG), but... Agreed! >I happen to find one possible clarification which could have been in >the latest address architecture document. In a previous discussion >back in 2002, we seem to have agreed the loopback interface does not >have to have a link-local address (with the "fe80::/10" prefix): > >http://www.atm.tut.fi/list-archive/ipng/msg02583.html > >...despite the requirement in Section 2.1 of >draft-ietf-ipv6-addr-arch-v4-04.txt: > > All interfaces are required to have at least one link-local unicast > address (see Section 2.8 for additional required addresses). > >(this should be generally interpreted that even the loopback interface >are required to have at least one fe80::xxx address) Possibly, however from Section 2.5.3 "The Loopback Address" it says: 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. I read this as saying the loopback address is the link-local unicast address of the loopback interface and thus meets the requirement in section 2.8. Does this resolve the issue you are raising? Bob >It would be great if this clarification could be incorporated into the >forthcoming RFC in the editorial stage, but I'm afraid this is beyond >a purely editorial change. (And if so, I won't push it. We'll simply >wait for the time when we work on addr-arch-v5...) > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 17 01:40:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj9aO-0005oq-MJ; Fri, 17 Jun 2005 01:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj9aM-0005oh-Fe for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 01:40:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23872 for ; Fri, 17 Jun 2005 01:40:09 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj9xM-00058Z-4X for ipv6@ietf.org; Fri, 17 Jun 2005 02:03:59 -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 6BDB01521B; Fri, 17 Jun 2005 14:43:50 +0900 (JST) Date: Fri, 17 Jun 2005 14:40:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden In-Reply-To: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> References: <6.2.1.2.2.20050616164419.02b731c8@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: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 16 Jun 2005 16:56:27 -0700, >>>>> Bob Hinden said: >> All interfaces are required to have at least one link-local unicast >> address (see Section 2.8 for additional required addresses). >> >> (this should be generally interpreted that even the loopback interface >> are required to have at least one fe80::xxx address) > Possibly, however from Section 2.5.3 "The Loopback Address" it says: > 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. > I read this as saying the loopback address is the link-local unicast > address of the loopback interface and thus meets the requirement in section > 2.8. > Does this resolve the issue you are raising? Ah, yes, and I should have been more careful before sending the message...RFC3513(addr-arch-v3) already has this change, which is not in RFC2372 and is probably a result of the previous discussion. Thanks for the clarification, and sorry about the noise. 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 Jun 17 01:47:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj9he-00072f-F6; Fri, 17 Jun 2005 01:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj9hc-000729-NW for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 01:47:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24343 for ; Fri, 17 Jun 2005 01:47: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 1DjA4e-0005k0-6S for ipv6@ietf.org; Fri, 17 Jun 2005 02:11:29 -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 7D7E51521B; Fri, 17 Jun 2005 14:51:23 +0900 (JST) Date: Fri, 17 Jun 2005 14:47:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela In-Reply-To: <200506170516.j5H5GoCN011651@moth.iki.fi> References: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> <200506170516.j5H5GoCN011651@moth.iki.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: 2409bba43e9c8d580670fda8b695204a Cc: ipv6@ietf.org, bob.hinden@nokia.com Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 17 Jun 2005 08:16:50 +0300, >>>>> Markku Savela said: >> Possibly, however from Section 2.5.3 "The Loopback Address" it says: >> >> 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. > Hmm.. i've missed this. For me loopback address has always had a "node > local" scope, and it seems to work fine logically. We should first note that the notion of "node local" scope was deprecated in RFC3513. But I suspect there is almost no difference in practice between (now deprecated) "node-local" and "link-local of the loopback link", in that addresses of those scopes should not be leaked outside the node. (So, it's not surprising that "it seems to work fine", whether the official definition is "node-local" or "link-local of the loopback link"). 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 Jun 17 10:32:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHtx-0007by-Mk; Fri, 17 Jun 2005 10:32:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjHtv-0007bt-PL for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 10:32:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23216 for ; Fri, 17 Jun 2005 10:32:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjIH2-0000Tq-24 for ipv6@ietf.org; Fri, 17 Jun 2005 10:56:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5HE2Am06098; Fri, 17 Jun 2005 07:02:10 -0700 X-mProtect: <200506171402> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp161230.americas.nokia.com (10.241.161.230, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdCXvht1; Fri, 17 Jun 2005 07:02:09 PDT Message-Id: <6.2.1.2.2.20050617073030.02c91e38@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 17 Jun 2005 07:32:27 -0700 To: =?iso-2022-jp?Q?ext_JINMEI_Tatuya_/_=1B=24B=3F=40L=40C=23=3AH=1B=28B?= From: Bob Hinden In-Reply-To: References: <6.2.1.2.2.20050616164419.02b731c8@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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, >Ah, yes, and I should have been more careful before sending the >message...RFC3513(addr-arch-v3) already has this change, which is not >in RFC2372 and is probably a result of the previous discussion. > >Thanks for the clarification, and sorry about the noise. No problem. I was glad to find the text too :-) 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 Jun 17 11:01:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjILd-0004wp-T9; Fri, 17 Jun 2005 11:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj9F2-0001Yk-Gl for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 01:18:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22105 for ; Fri, 17 Jun 2005 01:18:07 -0400 (EDT) Received: from burp.tkv.asdf.org ([212.16.99.49] helo=moth.iki.fi ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj9c3-0003cv-Md for ipv6@ietf.org; Fri, 17 Jun 2005 01:41:57 -0400 Received: from moth.iki.fi (msa@localhost [127.0.0.1]) by moth.iki.fi (8.13.4/8.13.4/Debian-3) with ESMTP id j5H5HFVP011665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jun 2005 08:17:30 +0300 Received: (from msa@localhost) by moth.iki.fi (8.13.4/8.13.4/Submit) id j5H5GoCN011651; Fri, 17 Jun 2005 08:16:50 +0300 Date: Fri, 17 Jun 2005 08:16:50 +0300 Message-Id: <200506170516.j5H5GoCN011651@moth.iki.fi> From: Markku Savela To: bob.hinden@nokia.com In-reply-to: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> (message from Bob Hinden on Thu, 16 Jun 2005 16:56:27 -0700) References: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 17 Jun 2005 11:01:30 -0400 Cc: ipv6@ietf.org, jinmei@isl.rdc.toshiba.co.jp Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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: Bob Hinden > Possibly, however from Section 2.5.3 "The Loopback Address" it says: > > 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. Hmm.. i've missed this. For me loopback address has always had a "node local" scope, and it seems to work fine logically. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 17 11:08:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjISG-0005xb-1H; Fri, 17 Jun 2005 11:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjISD-0005xK-Dj for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 11:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25760 for ; Fri, 17 Jun 2005 11:08:18 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjIpK-000388-QY for ipv6@ietf.org; Fri, 17 Jun 2005 11:32:15 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5HEbdT08008 for ; Fri, 17 Jun 2005 07:37:39 -0700 X-mProtect: <200506171437> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp161230.americas.nokia.com (10.241.161.230, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdGe22yP; Fri, 17 Jun 2005 07:37:37 PDT Message-Id: <6.2.1.2.2.20050617080738.02c71280@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 17 Jun 2005 08:07:55 -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: 4b800b1eab964a31702fa68f1ff0e955 Subject: Fwd: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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 >To: ietf-announce@ietf.org >From: ietf-announce-bounces@ietf.org >Date: Fri, 17 Jun 2005 00:00:02 -0400 >X-Spam-Score: 0.3 (/) >X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b >Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting > in Paris, France >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org >X-OriginalArrivalTime: 17 Jun 2005 05:37:17.0635 (UTC) >FILETIME=[9FB0C930:01C572FE] > > >There are two (2) Internet-Draft cutoff dates for the 63rd >IETF Meeting in Paris, France: > >July 11th: Cutoff Date for Initial (i.e., version -00) >Internet-Draft Submissions > >All initial Internet-Drafts (version -00) must be submitted by Monday, >July 11th at 9:00 AM ET. As always, all initial submissions with a >filename beginning with "draft-ietf" must be approved by the >appropriate WG Chair before they can be processed or announced. The >Secretariat would appreciate receiving WG Chair approval by Tuesday, >July 5th at 9:00 AM ET. > >July 18th: Cutoff Date for Revised (i.e., version -01 and higher) >Internet-Draft Submissions > >All revised Internet-Drafts (version -01 and higher) must be submitted >by Monday, July 18th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their respective >cutoff dates will not be made available in the Internet-Drafts >directory or announced until on or after Monday, August 1st at 9:00 >AM ET, when Internet-Draft posting resumes. Please do not wait until >the last minute to submit. > >PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or >revised Internet-Draft after their respective cutoff deadlines, then >your document will be retained and posted when Internet-Draft >processing resumes. You will no longer be required to resubmit the >document. > >Thank you for your understanding and cooperation. If you have any >questions or concerns, then please send a message to >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other significant dates >for the 63rd IETF Meeting can be found at >http://www.ietf.org/meetings/cutoff_dates_63.html. > >_______________________________________________ >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 Fri Jun 17 11: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 1DjIbL-000057-Lz; Fri, 17 Jun 2005 11: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 1DjIbJ-000052-0Y for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 11:17:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26474 for ; Fri, 17 Jun 2005 11:17:42 -0400 (EDT) Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjIyP-0003qf-RE for ipv6@ietf.org; Fri, 17 Jun 2005 11:41:39 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by atlrel9.hp.com (Postfix) with ESMTP id 59151401D5; Fri, 17 Jun 2005 11:17:36 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id DFDFE2361; Fri, 17 Jun 2005 11:17:35 -0400 (EDT) Received: from galen.zko.hp.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j5HFHUl0002569214; Fri, 17 Jun 2005 11:17:35 -0400 (EDT) From: Vlad Yasevich To: Markku Savela In-Reply-To: <200506170516.j5H5GoCN011651@moth.iki.fi> References: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> <200506170516.j5H5GoCN011651@moth.iki.fi> Content-Type: text/plain Organization: Linux and Open Source Lab Date: Fri, 17 Jun 2005 11:17:29 -0400 Message-Id: <1119021450.22861.8.camel@galen.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, bob.hinden@nokia.com, JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 2005-06-17 at 08:16 +0300, Markku Savela wrote: > > From: Bob Hinden > > > Possibly, however from Section 2.5.3 "The Loopback Address" it says: > > > > 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. > > Hmm.. i've missed this. For me loopback address has always had a "node > local" scope, and it seems to work fine logically. > But it works equally well with it being a link-local addresses belonging to a virtual loopback link. I've updated one implementation to use this new scoping. The change was minimal and actually made things easier. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 17 14:14:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjLKG-0006xf-SD; Fri, 17 Jun 2005 14:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjLKE-0006xQ-0C for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 14:12:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09219 for ; Fri, 17 Jun 2005 14:12:16 -0400 (EDT) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjLhM-0007tU-0r for ipv6@ietf.org; Fri, 17 Jun 2005 14:36:13 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.4/8.13.4/Debian-3) with ESMTP id j5HICC72003968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jun 2005 21:12:12 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.4/8.13.4/Submit) id j5HIC3ZD003961; Fri, 17 Jun 2005 21:12:03 +0300 Date: Fri, 17 Jun 2005 21:12:03 +0300 Message-Id: <200506171812.j5HIC3ZD003961@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp In-reply-to: References: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> <200506170516.j5H5GoCN011651@moth.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: bob.hinden@nokia.com, ipv6@ietf.org Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= > > We should first note that the notion of "node local" scope was > deprecated in RFC3513. But I suspect there is almost no difference in > practice between (now deprecated) "node-local" and "link-local of the > loopback link", in that addresses of those scopes should not be leaked > outside the node. I have to keep using the "node-local scope", because implementation architecture puts it into good use internally. There is some difference in link local and node local: - link local addresses can actually appear on the link, outside the node itself. - link local addresses need the scope id to be unique - node local addresses can never escape the node itself. So, I'm a bit puzzled why node-local was deprecated. It's a useful concept, even if all implementations do not put it into any good use. I guess I have to view it as internal implementation issue, and keep using it. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Jun 17 20:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjRXE-0003AB-0H; Fri, 17 Jun 2005 20:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjRXB-00039u-70 for ipv6@megatron.ietf.org; Fri, 17 Jun 2005 20:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06542 for ; Fri, 17 Jun 2005 20:50: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 1DjRuM-0001cM-Ta for ipv6@ietf.org; Fri, 17 Jun 2005 21:14:04 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4876515218; Sat, 18 Jun 2005 09:53:33 +0900 (JST) Date: Sat, 18 Jun 2005 09:49:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela In-Reply-To: <200506171812.j5HIC3ZD003961@burp.tkv.asdf.org> References: <6.2.1.2.2.20050616164419.02b731c8@mailhost.iprg.nokia.com> <200506170516.j5H5GoCN011651@moth.iki.fi> <200506171812.j5HIC3ZD003961@burp.tkv.asdf.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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipv6@ietf.org, bob.hinden@nokia.com Subject: Re: link-local address on loopback interface X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 17 Jun 2005 21:12:03 +0300, >>>>> Markku Savela said: > I have to keep using the "node-local scope", because implementation > architecture puts it into good use internally. > There is some difference in link local and node local: > - link local addresses can actually appear on the link, outside the > node itself. > - link local addresses need the scope id to be unique > - node local addresses can never escape the node itself. > So, I'm a bit puzzled why node-local was deprecated. It's a useful > concept, even if all implementations do not put it into any good use. Node-local was deprecated by interface-local as per RFC3513. Interface-local has all the properties for the 'good use' you indicated above. This is also the case for "link-local of the link attached to a loopback interface'. I don't know if this answers your comment, though. But in any event, I believe the slight difference between node-local and interface-local doesn't matter for most users. 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 Jun 18 14:15:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Djhqu-0003gX-Vq; Sat, 18 Jun 2005 14:15:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Djhqt-0003gN-As for ipv6@megatron.ietf.org; Sat, 18 Jun 2005 14:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01054 for ; Sat, 18 Jun 2005 14:15:29 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjiEE-0003S6-9b for ipv6@ietf.org; Sat, 18 Jun 2005 14:39:39 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5IHijB12913; Sat, 18 Jun 2005 10:44:45 -0700 X-mProtect: <200506181744> Nokia Silicon Valley Messaging Protection Received: from danira-pool05114.americas.nokia.com (10.241.51.14, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdReVWpB; Sat, 18 Jun 2005 10:44:43 PDT Message-Id: <6.2.1.2.2.20050618111055.02c3fad8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 18 Jun 2005 11:15:04 -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: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: IPv6 WG Last Call: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org This starts a 1 week IPv6 working group last call on advancing: Title : IP Version 6 over PPP Author(s) : S. Varada, et al. Filename : draft-ietf-ipv6-over-ppp-v2-02.txt Pages : 15 Date : 2005-6-15 to Draft Standard. The chairs want to verify that all comments raised during the previous last call have been addresses. Please send substantive comments to the IPv6 mailing list. Editorial comments can be sent to the document editor. This last call will end on June 25, 2005. Regards, Bob & Brian IPv6 WG co-chairs -------------------------------------------------------------------- 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 Sun Jun 19 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 1DjqzA-0001ze-01; Sun, 19 Jun 2005 00:00:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Djqz8-0001zZ-Fi for ipv6@megatron.ietf.org; Sun, 19 Jun 2005 00:00:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10891 for ; Sun, 19 Jun 2005 00:00:35 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjrMY-0006Gf-IT for ipv6@ietf.org; Sun, 19 Jun 2005 00:24:52 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 24B32487 for ; Sun, 19 Jun 2005 00:00:15 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 19 Jun 2005 00:00:14 -0400 Message-Id: <20050619040015.24B32487@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 --------+------+--------+----------+------------------------ 26.67% | 4 | 26.87% | 18142 | bob.hinden@nokia.com 26.67% | 4 | 25.10% | 16951 | jinmei@isl.rdc.toshiba.co.jp 6.67% | 1 | 9.82% | 6631 | @ 6.67% | 1 | 9.80% | 6617 | internet-drafts@ietf.org 6.67% | 1 | 6.35% | 4288 | vladislav.yasevich@hp.com 6.67% | 1 | 5.98% | 4040 | msa@burp.tkv.asdf.org 6.67% | 1 | 5.53% | 3737 | msa@moth.iki.fi 6.67% | 1 | 5.51% | 3721 | fujisaki@syce.net 6.67% | 1 | 5.04% | 3401 | sra+ipng@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 15 |100.00% | 67528 | 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 Thu Jun 23 07:44:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQ8E-0008F0-FI; Thu, 23 Jun 2005 07:44:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQ8D-0008Ev-DU for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 07:44:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29608 for ; Thu, 23 Jun 2005 07:44:28 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlQWS-00075M-No for ipv6@ietf.org; Thu, 23 Jun 2005 08:09:37 -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 j5NBi7i3027872 for ; Thu, 23 Jun 2005 12:44:07 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA04097 for ; Thu, 23 Jun 2005 12:43:24 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j5NBhNW16325 for ipv6@ietf.org; Thu, 23 Jun 2005 12:43:23 +0100 Date: Thu, 23 Jun 2005 12:43:23 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050623114323.GF15500@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: ULAs, multicast and RFC3484 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 Hi, As part of our studies in IPv6 renumbering(*) in the 6NET project we've been looking at running ULAs alongside globals for internal communication stability through a renumbering event. We seem to have hit an issue with ULAs and multicast, that we'd like to get WG comment on. When a node is multiaddressed with ULA and global prefixes, and wishes to send to a globally scoped multicast group, RFC3484 policy will select the best match source address of equal scope. The 'snag' is that, as per section 3.3 of the ULA draft, ULAs are global scope. As a result, multicast traffic to global scope groups will be sent with ULA source addresses. We note that RFC 3879 on site local deprecation doesn't mention multicast, we suspect because the deprecation text was written pre-ULAs. RFC 3484 talks of scope comparisons in section 3.1, but the language of 'site locals' is now out of date. So, if this is an issue, should it be fixed by a recall of ULAs from the RFC editor's queue, or an update to RFC 3484? It seems a 3484 update is needed at some point due to the 'site local' references in it. Comments? -- Tim/::1 (*) See: http://www.6net.org/publications/deliverables/D3.6.1.pdf and http://www.6net.org/publications/deliverables/D3.6.2.pdf -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 08:22:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQio-0006tc-CE; Thu, 23 Jun 2005 08:22:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQim-0006tW-4X for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 08:22:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03607 for ; Thu, 23 Jun 2005 08:22:15 -0400 (EDT) Received: from 132.cust13.sa.dsl.ozemail.com.au ([210.84.236.132] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlR74-0000ef-Cj for ipv6@ietf.org; Thu, 23 Jun 2005 08:47:24 -0400 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 73B6562AAE; Thu, 23 Jun 2005 21:51:52 +0930 (CST) Date: Thu, 23 Jun 2005 21:51:51 +0930 From: Mark Smith To: Tim Chown Message-Id: <20050623215151.7e449691.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050623114323.GF15500@login.ecs.soton.ac.uk> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> 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: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Similar issue with host routing (Re: ULAs, multicast and RFC3484 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 Hi Tim, On Thu, 23 Jun 2005 12:43:23 +0100 Tim Chown wrote: > Hi, > > As part of our studies in IPv6 renumbering(*) in the 6NET project we've > been looking at running ULAs alongside globals for internal communication > stability through a renumbering event. > > We seem to have hit an issue with ULAs and multicast, that we'd like to > get WG comment on. > > When a node is multiaddressed with ULA and global prefixes, and wishes > to send to a globally scoped multicast group, RFC3484 policy will select > the best match source address of equal scope. The 'snag' is that, as > per section 3.3 of the ULA draft, ULAs are global scope. As a result, > multicast traffic to global scope groups will be sent with ULA source > addresses. > > We note that RFC 3879 on site local deprecation doesn't mention multicast, > we suspect because the deprecation text was written pre-ULAs. > > RFC 3484 talks of scope comparisons in section 3.1, but the language of > 'site locals' is now out of date. > > So, if this is an issue, should it be fixed by a recall of ULAs from the > RFC editor's queue, or an update to RFC 3484? It seems a 3484 update > is needed at some point due to the 'site local' references in it. > > Comments? > Sorry not to address your question specifically, however I think there might be a similar issue regarding using host routes and multicast, which may also necessitate an update to RFC3484. Using host routes has been proposed as a method of topology hiding in one of the v6ops drafts (the NAP one). I don't want to thread-jack any discussion on your issue, I've changed the topic so hopefully they can be split and discussed separately if necessary. Here is what I think the issue is. If the end-node has a link-local prefix, and a /128 prefix-length ULA or global address, and it wants to perform a link-local scoped multicast on a broadcast multi-access link, I think the following would occur : (a) if the source address of the link-local scoped multicast isn't selected, then RFC3484 would mean that the nodes link-local address would be used as the multicast source address. All good. (b) if the source address of the link-local scoped multicast was selected as the /128 ULA or global address, to where is the multicast actually sent ? I can think of a couple of options : - A /128 prefix length in routing terms indicates that everything else is offlink. Should the multicast be dropped, as there is no other onlink destinations for link-local scoped multicasts to go to ? Alternatively, at the IPv6 layer, with this /128 prefix length, this node's relationship with the routers is similar to the node having individual point-to-point links to the routers it has learned of via RAs, even though the underlying layer 2 link technology is broadcast multi-access. Should the multicast be sent to the routers it has learned of through RAs, possibly using unicast link layer destinations to ensure other routers don't receive this multicast (obviously the node has to replicate the packet to do this) ? - Alternatively, the view could be that the node should only send the multicast to nodes that it knows it is attached to directly at layer 2. There is also some abiguity here. Does this mean : o only the routers it has learned of via RAs. o the routers it has learned of via RAs, as well as nodes that it has learned are layer 2 peers via ICMP redirects In either of these cases, the node may need to be selective as to which of it's layer 2 peers it sends the multicast to, which possibly means unicasting at layer 2 the multicast to the selected peers. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 09:16:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlRYm-0007ug-HP; Thu, 23 Jun 2005 09:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlRYj-0007uT-Qc for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 09:15:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08440 for ; Thu, 23 Jun 2005 09:15:56 -0400 (EDT) Received: from 132.cust13.sa.dsl.ozemail.com.au ([210.84.236.132] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlRx3-0003Ax-1K for ipv6@ietf.org; Thu, 23 Jun 2005 09:41:06 -0400 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 9CFAB62AAE; Thu, 23 Jun 2005 22:45:40 +0930 (CST) Date: Thu, 23 Jun 2005 22:45:40 +0930 From: Mark Smith To: Mark Smith Message-Id: <20050623224540.347ddfab.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050623215151.7e449691.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <20050623215151.7e449691.ipng@69706e6720323030352d30312d31340a.nosense.org> 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: tjc@ecs.soton.ac.uk, ipv6@ietf.org Subject: Re: Similar issue with host routing (Re: ULAs, multicast and RFC3484 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 On Thu, 23 Jun 2005 21:51:51 +0930 Mark Smith wrote: > > Sorry not to address your question specifically, however I think there > might be a similar issue regarding using host routes and multicast, > which may also necessitate an update to RFC3484. Using host routes has > been proposed as a method of topology hiding in one of the v6ops drafts > (the NAP one). I don't want to thread-jack any discussion on your issue, > I've changed the topic so hopefully they can be split and discussed > separately if necessary. > > Here is what I think the issue is. If the end-node has a link-local > prefix, and a /128 prefix-length ULA or global address, and it wants to > perform a link-local scoped multicast on a broadcast multi-access link, > I think the following would occur : > Hmm, the multicast link-local issue I described might not be an issue, as it seems that according to draft-ietf-ipv6-addr-arch-v4-04.txt the interface id must be 64 bits in size, indicating that a /128 would be invalid on the nodes interface, although valid in an upstream router's route table. I'll have to do a bit more thinking as to how host routing would work from an end-nodes point of view, when trying to achieve topology hiding or rather subnet hiding from nodes located outside the assigned local /48(s). Sorry for the noise, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 10:03:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSJ6-0000Hh-0N; Thu, 23 Jun 2005 10:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSJ2-0000Dx-Qp for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 10:03:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13353 for ; Thu, 23 Jun 2005 10:03:46 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlShL-0005V5-4W for ipv6@ietf.org; Thu, 23 Jun 2005 10:28:57 -0400 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel10.hp.com (Postfix) with ESMTP id 72CBFE2D; Thu, 23 Jun 2005 07:03:38 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 198D3526; Thu, 23 Jun 2005 07:03:35 -0700 (PDT) Received: from galen.zko.hp.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j5NE3br0000592570; Thu, 23 Jun 2005 10:03:37 -0400 (EDT) From: Vlad Yasevich To: Tim Chown In-Reply-To: <20050623114323.GF15500@login.ecs.soton.ac.uk> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> Content-Type: text/plain Organization: Linux and Open Source Lab Date: Thu, 23 Jun 2005 10:03:36 -0400 Message-Id: <1119535416.6872.50.camel@galen.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 Tim Wouldn't an update to a policy table be enough to resolve the problem? -vlad On Thu, 2005-06-23 at 12:43 +0100, Tim Chown wrote: > Hi, > > As part of our studies in IPv6 renumbering(*) in the 6NET project we've > been looking at running ULAs alongside globals for internal communication > stability through a renumbering event. > > We seem to have hit an issue with ULAs and multicast, that we'd like to > get WG comment on. > > When a node is multiaddressed with ULA and global prefixes, and wishes > to send to a globally scoped multicast group, RFC3484 policy will select > the best match source address of equal scope. The 'snag' is that, as > per section 3.3 of the ULA draft, ULAs are global scope. As a result, > multicast traffic to global scope groups will be sent with ULA source > addresses. > > We note that RFC 3879 on site local deprecation doesn't mention multicast, > we suspect because the deprecation text was written pre-ULAs. > > RFC 3484 talks of scope comparisons in section 3.1, but the language of > 'site locals' is now out of date. > > So, if this is an issue, should it be fixed by a recall of ULAs from the > RFC editor's queue, or an update to RFC 3484? It seems a 3484 update > is needed at some point due to the 'site local' references in it. > > Comments? > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 10:14:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSPL-0001ag-Lb; Thu, 23 Jun 2005 10:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSPJ-0001aC-8g for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 10:10:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14159 for ; Thu, 23 Jun 2005 10:10:15 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlSnd-0005qo-3j for ipv6@ietf.org; Thu, 23 Jun 2005 10:35:26 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j5NE9mIh000463; Thu, 23 Jun 2005 16:09:48 +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 j5NE9lX0018110; Thu, 23 Jun 2005 16:09:48 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j5NE9lS7018109; Thu, 23 Jun 2005 16:09:47 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 23 Jun 2005 16:09:47 +0200 From: Stig Venaas To: Vlad Yasevich Message-ID: <20050623140947.GH17928@storhaugen.uninett.no> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1119535416.6872.50.camel@galen.zko.hp.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Tim Chown , ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 On Thu, Jun 23, 2005 at 10:03:36AM -0400, Vlad Yasevich wrote: > Tim > > Wouldn't an update to a policy table be enough to resolve the problem? Yes, but isn't it best that the default policy does the right thing? Else everyone with ULA doing global multicast will need to update their policies. Of course vendors could use their own default policy that is different from 3484's policy... Stig > -vlad > > On Thu, 2005-06-23 at 12:43 +0100, Tim Chown wrote: > > Hi, > > > > As part of our studies in IPv6 renumbering(*) in the 6NET project we've > > been looking at running ULAs alongside globals for internal communication > > stability through a renumbering event. > > > > We seem to have hit an issue with ULAs and multicast, that we'd like to > > get WG comment on. > > > > When a node is multiaddressed with ULA and global prefixes, and wishes > > to send to a globally scoped multicast group, RFC3484 policy will select > > the best match source address of equal scope. The 'snag' is that, as > > per section 3.3 of the ULA draft, ULAs are global scope. As a result, > > multicast traffic to global scope groups will be sent with ULA source > > addresses. > > > > We note that RFC 3879 on site local deprecation doesn't mention multicast, > > we suspect because the deprecation text was written pre-ULAs. > > > > RFC 3484 talks of scope comparisons in section 3.1, but the language of > > 'site locals' is now out of date. > > > > So, if this is an issue, should it be fixed by a recall of ULAs from the > > RFC editor's queue, or an update to RFC 3484? It seems a 3484 update > > is needed at some point due to the 'site local' references in it. > > > > Comments? > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 10: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 1DlSUL-0002fE-D9; Thu, 23 Jun 2005 10: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 1DlSUJ-0002f8-3B for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 10:15:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14786 for ; Thu, 23 Jun 2005 10:15:25 -0400 (EDT) Received: from paddock.ermy.net ([62.189.30.132]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlSsd-00061P-1S for ipv6@ietf.org; Thu, 23 Jun 2005 10:40:36 -0400 Received: (qmail 12101 invoked from network); 23 Jun 2005 14:24:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 23 Jun 2005 14:24:31 -0000 In-Reply-To: <1119535416.6872.50.camel@galen.zko.hp.com> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D39A26D-CD64-4985-8E2F-51D81730D701@ecs.soton.ac.uk> Content-Transfer-Encoding: 7bit From: "Mark K. Thompson" Date: Thu, 23 Jun 2005 15:15:05 +0100 To: Vlad Yasevich X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 On 23 Jun 2005, at 15:03, Vlad Yasevich wrote: > > Wouldn't an update to a policy table be enough to resolve the problem? It's more than one update, I think: If the candidate destination address is from a fc00::/7 prefix in the set that are either local to this network or a prefix at a network with whom I have routing agreements, then prefer a local ULA source address; otherwise if the candidate destination address is from any other fc00::/7 prefix, never prefer our ULA source address Perhaps the second clause is not necessary where the first rules bump local ULAs up the preferred source address list (one rule per routable fc00::/7 prefix) I can see a straw poll of 3484 implementations on the horizon... Mark/ -- Dr Mark K. Thompson Electronics and Computer Science a School of the University of Southampton, UK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 10:47:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSyr-0000Ye-Pp; Thu, 23 Jun 2005 10:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSyp-0000YF-Kw for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 10:46:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18731 for ; Thu, 23 Jun 2005 10:46:57 -0400 (EDT) Received: from ccerelbas01.cce.hp.com ([161.114.21.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTN9-0007kL-4u for ipv6@ietf.org; Thu, 23 Jun 2005 11:12:09 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ccerelbas01.cce.hp.com (Postfix) with ESMTP id 2352820000FE; Thu, 23 Jun 2005 09:46:46 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id B185A11D8; Thu, 23 Jun 2005 09:46:45 -0500 (CDT) Received: from galen.zko.hp.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j5NEkid0001533036; Thu, 23 Jun 2005 10:46:45 -0400 (EDT) From: Vlad Yasevich To: Stig Venaas In-Reply-To: <20050623140947.GH17928@storhaugen.uninett.no> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> Content-Type: text/plain Organization: Linux and Open Source Lab Date: Thu, 23 Jun 2005 10:46:44 -0400 Message-Id: <1119538004.6872.57.camel@galen.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 On Thu, 2005-06-23 at 16:09 +0200, Stig Venaas wrote: > On Thu, Jun 23, 2005 at 10:03:36AM -0400, Vlad Yasevich wrote: > > Tim > > > > Wouldn't an update to a policy table be enough to resolve the problem? > > Yes, but isn't it best that the default policy does the right thing? > I agree. Is this something that may be mentioned in ULA spec? > Else everyone with ULA doing global multicast will need to update their > policies. Of course vendors could use their own default policy that is > different from 3484's policy... Yes. I've always considered policy from 3484 an example that will be modified by the end-user. That's why it's there. It gives a really basic default. If you want to be multiaddresses with ULA and global prefixes, you need to tweak things. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 10:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlT1s-0001a0-37; Thu, 23 Jun 2005 10:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlT1q-0001Zr-DO for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 10:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19256 for ; Thu, 23 Jun 2005 10:50:04 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTQB-0007xF-TB for ipv6@ietf.org; Thu, 23 Jun 2005 11:15:16 -0400 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel10.hp.com (Postfix) with ESMTP id 970672BC7; Thu, 23 Jun 2005 07:50:04 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 2D651532; Thu, 23 Jun 2005 07:50:01 -0700 (PDT) Received: from galen.zko.hp.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j5NEnwf0001904708; Thu, 23 Jun 2005 10:50:03 -0400 (EDT) From: Vlad Yasevich To: "Mark K. Thompson" In-Reply-To: <1D39A26D-CD64-4985-8E2F-51D81730D701@ecs.soton.ac.uk> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <1D39A26D-CD64-4985-8E2F-51D81730D701@ecs.soton.ac.uk> Content-Type: text/plain Organization: Linux and Open Source Lab Date: Thu, 23 Jun 2005 10:49:57 -0400 Message-Id: <1119538198.6872.62.camel@galen.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 On Thu, 2005-06-23 at 15:15 +0100, Mark K. Thompson wrote: > On 23 Jun 2005, at 15:03, Vlad Yasevich wrote: > > > > Wouldn't an update to a policy table be enough to resolve the problem? > > It's more than one update, I think: My point was more that an update (or updates) to the policy table would solve this. I guess the number of updates depends on how the policy is implemented. You could always prefer global over ULA for multicast, and will fall back to ULAs only if all global prefixes are deprecated. This is really and end-user decision. -vlad > > If the candidate destination address is from a fc00::/7 prefix > in the set that are either local to this network or a prefix at a > network with whom I have routing agreements, then prefer a local ULA > source address; otherwise if the candidate destination address is > from any other fc00::/7 prefix, never prefer our ULA source address > > Perhaps the second clause is not necessary where the first rules bump > local ULAs up the preferred source address list (one rule per > routable fc00::/7 prefix) > > I can see a straw poll of 3484 implementations on the horizon... > > Mark/ > > -- > Dr Mark K. Thompson > Electronics and Computer Science > a School of the University of Southampton, UK > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 10:53:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlT5B-0002aH-HA; Thu, 23 Jun 2005 10:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlT59-0002Yb-P5 for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 10:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19680 for ; Thu, 23 Jun 2005 10:53:29 -0400 (EDT) Received: from 132.cust13.sa.dsl.ozemail.com.au ([210.84.236.132] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTTT-00086x-UI for ipv6@ietf.org; Thu, 23 Jun 2005 11:18:41 -0400 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 94BBC62AAE; Fri, 24 Jun 2005 00:23:17 +0930 (CST) Date: Fri, 24 Jun 2005 00:23:17 +0930 From: Mark Smith To: Vlad Yasevich Message-Id: <20050624002317.2be54643.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <1119538004.6872.57.camel@galen.zko.hp.com> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> <1119538004.6872.57.camel@galen.zko.hp.com> 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Stig.Venaas@uninett.no Subject: Re: ULAs, multicast and RFC3484 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 On Thu, 23 Jun 2005 10:46:44 -0400 Vlad Yasevich wrote: > On Thu, 2005-06-23 at 16:09 +0200, Stig Venaas wrote: > > On Thu, Jun 23, 2005 at 10:03:36AM -0400, Vlad Yasevich wrote: > > > Tim > > > > > > Wouldn't an update to a policy table be enough to resolve the problem? > > > > Yes, but isn't it best that the default policy does the right thing? > > > > I agree. Is this something that may be mentioned in ULA spec? > > > Else everyone with ULA doing global multicast will need to update their > > policies. Of course vendors could use their own default policy that is > > different from 3484's policy... > > Yes. I've always considered policy from 3484 an example that will be > modified by the end-user. That's why it's there. It gives a really > basic default. If you want to be multiaddresses with ULA and global > prefixes, you need to tweak things. > I'd think ULAs and globals deployed in parallel would be the most common case, so I'd think it should just work "out of the box" without having to tweak anything. Without putting a bit of effort into it i.e. off the top of my head, I can't think of scenarios where ULAs wouldn't be deployed in parallel with globals. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 11:02:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTDc-0004dj-Nu; Thu, 23 Jun 2005 11:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTDa-0004db-1Q for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 11:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20698 for ; Thu, 23 Jun 2005 11:02:12 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTbu-00009J-JA for ipv6@ietf.org; Thu, 23 Jun 2005 11:27:24 -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 j5NF21Ih013260; Thu, 23 Jun 2005 17:02:01 +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 j5NF213N018412; Thu, 23 Jun 2005 17:02:01 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j5NF21R1018411; Thu, 23 Jun 2005 17:02:01 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 23 Jun 2005 17:02:01 +0200 From: Stig Venaas To: Vlad Yasevich Message-ID: <20050623150201.GM17928@storhaugen.uninett.no> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> <1119538004.6872.57.camel@galen.zko.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1119538004.6872.57.camel@galen.zko.hp.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 On Thu, Jun 23, 2005 at 10:46:44AM -0400, Vlad Yasevich wrote: > On Thu, 2005-06-23 at 16:09 +0200, Stig Venaas wrote: > > On Thu, Jun 23, 2005 at 10:03:36AM -0400, Vlad Yasevich wrote: > > > Tim > > > > > > Wouldn't an update to a policy table be enough to resolve the problem? > > > > Yes, but isn't it best that the default policy does the right thing? > > > > I agree. Is this something that may be mentioned in ULA spec? Too late I think, it's already in rfc ed queue. However 3484 should be updated anyway to remove site-locals and something about ULA could then be added. This would be a trivial change. Note that the ULA draft, draft-ietf-ipv6-unique-local-addr-09.txt is vague regarding scopes: - In practice, applications may treat these addresses like global scoped addresses. which I think is wrong if host also has normal global unicast addresses. But wording indicates that they are not really global scoped addresses. Also 3.3 Scope Definition By default, the scope of these addresses is global. That is, they are not limited by ambiguity like the site-local addresses defined in [ADDARCH]. Rather, these prefixes are globally unique, and as such, their applicability is greater than site-local addresses. Their limitation is in the routability of the prefixes, which is limited to a site and any explicit routing agreements with other sites to propagate them (also see section 4.1). Also, unlike site-locals, a site may have more than one of these prefixes and use them at the same time. What does default mean here? Stig > > Else everyone with ULA doing global multicast will need to update their > > policies. Of course vendors could use their own default policy that is > > different from 3484's policy... > > Yes. I've always considered policy from 3484 an example that will be > modified by the end-user. That's why it's there. It gives a really > basic default. If you want to be multiaddresses with ULA and global > prefixes, you need to tweak things. > > -vlad > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 11:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTyG-0006zA-IB; Thu, 23 Jun 2005 11:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTyE-0006z5-0T for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 11:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26469 for ; Thu, 23 Jun 2005 11:50:23 -0400 (EDT) Received: from paddock.ermy.net ([62.189.30.132]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlUMY-0002g1-Av for ipv6@ietf.org; Thu, 23 Jun 2005 12:15:36 -0400 Received: (qmail 2113 invoked from network); 23 Jun 2005 15:59:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 23 Jun 2005 15:59:37 -0000 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <20050624002317.2be54643.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> <1119538004.6872.57.camel@galen.zko.hp.com> <20050624002317.2be54643.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69E2ED36-2263-4E00-A961-A21ABD2FAB5B@ecs.soton.ac.uk> Content-Transfer-Encoding: 7bit From: "Mark K. Thompson" Date: Thu, 23 Jun 2005 16:50:12 +0100 To: ipv6@ietf.org X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: Re: ULAs, multicast and RFC3484 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 On 23 Jun 2005, at 15:53, Mark Smith wrote: > On Thu, 23 Jun 2005 10:46:44 -0400 > Vlad Yasevich wrote: >> >> I've always considered policy from 3484 an example that will be >> modified by the end-user. That's why it's there. It gives a really >> basic default. If you want to be multiaddresses with ULA and global >> prefixes, you need to tweak things. But for sure there are basic policies that could (should?) be enabled by default so that ULAs aren't preferred as source addresses for anything other than potential ULA destinations (e.g. due to sites misbehaving by putting ULAs in global DNS RRs) I'm rapidly coming to the same conclusion as Fred :-/ The use of site locals (sorry - i'll pay penance later) and, after FEC0's deprecation, ULAs that we have motivation for is disconnected networks that have topology - principally sensor nets and such beasts as community wireless networks. Both of these application domains have a requirement for provider independent addressing or survivable, swift and automated renumbering that requires little to no administrator intervention. The latter hurts my head, even after working on an IPv6 Renumbering project ;-) > I'd think ULAs and globals deployed in parallel would be the most > common > case, so I'd think it should just work "out of the box" without having > to tweak anything. Absolutely. > Without putting a bit of effort into it i.e. off the > top of my head, I can't think of scenarios where ULAs wouldn't be > deployed in parallel with globals. Either scenario above can start out as just ULA with potentially ephemeral and variable availability of globals. Mark/ -- Dr Mark K. Thompson Electronics and Computer Science a School of the University of Southampton, UK -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 23 12:02:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlU9c-00010w-Vd; Thu, 23 Jun 2005 12:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlU9a-00010o-MI for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 12:02:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27623 for ; Thu, 23 Jun 2005 12:02:08 -0400 (EDT) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUXw-0003Ii-9Z for ipv6@ietf.org; Thu, 23 Jun 2005 12:27:21 -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 j5NG22i3007122 for ; Thu, 23 Jun 2005 17:02:02 +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 RAA00039 for ; Thu, 23 Jun 2005 17:01:27 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j5NG1QD23616 for ipv6@ietf.org; Thu, 23 Jun 2005 17:01:26 +0100 Date: Thu, 23 Jun 2005 17:01:26 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050623160126.GS20820@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> <1119538004.6872.57.camel@galen.zko.hp.com> <20050624002317.2be54643.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050624002317.2be54643.ipng@69706e6720323030352d30312d31340a.nosense.org> 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: d6b246023072368de71562c0ab503126 Subject: Re: ULAs, multicast and RFC3484 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 On Fri, Jun 24, 2005 at 12:23:17AM +0930, Mark Smith wrote: > > I'd think ULAs and globals deployed in parallel would be the most common > case, so I'd think it should just work "out of the box" without having > to tweak anything. Without putting a bit of effort into it i.e. off the > top of my head, I can't think of scenarios where ULAs wouldn't be > deployed in parallel with globals. There is the intermittently connected network, that uses ULAs internally, but will also use globals when connected externally and multi-addressed, but then drop back to ULA-only when its uplink disappears again. An example might be a community wireless network, where ADSL uplinks may be advertised and removed over time. -- 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 Jun 23 12:04:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUBb-0001Jv-Lz; Thu, 23 Jun 2005 12:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUBZ-0001Jn-CA for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 12:04:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27887 for ; Thu, 23 Jun 2005 12:04: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 1DlUZv-0003SM-DB for ipv6@ietf.org; Thu, 23 Jun 2005 12:29:23 -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 j5NG4Bi3007153 for ; Thu, 23 Jun 2005 17:04:11 +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 RAA00281 for ; Thu, 23 Jun 2005 17:03:42 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j5NG3gb23649 for ipv6@ietf.org; Thu, 23 Jun 2005 17:03:42 +0100 Date: Thu, 23 Jun 2005 17:03:42 +0100 From: Tim Chown To: ipv6@ietf.org Message-ID: <20050623160342.GT20820@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> <1119538004.6872.57.camel@galen.zko.hp.com> <20050623150201.GM17928@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050623150201.GM17928@storhaugen.uninett.no> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Re: ULAs, multicast and RFC3484 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 On Thu, Jun 23, 2005 at 05:02:01PM +0200, Stig Venaas wrote: > > Too late I think, it's already in rfc ed queue. However 3484 should be > updated anyway to remove site-locals and something about ULA could then > be added. This would be a trivial change. > > Note that the ULA draft, draft-ietf-ipv6-unique-local-addr-09.txt is > vague regarding scopes: Exactly - two issues here - one is removing some 'loose' language from the ULA draft, the other is a 3484 update to consider ULAs in place of site locals. The former could be an 'editorial' change, if meaning is preserved? -- 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 Jun 23 20:14:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlbnH-0002QL-6o; Thu, 23 Jun 2005 20:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlbnE-0002QC-IS for ipv6@megatron.ietf.org; Thu, 23 Jun 2005 20:11:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18660 for ; Thu, 23 Jun 2005 20:11:35 -0400 (EDT) Received: from 132.cust13.sa.dsl.ozemail.com.au ([210.84.236.132] helo=ubu.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlcBd-0006GX-F3 for ipv6@ietf.org; Thu, 23 Jun 2005 20:36:51 -0400 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id BB1BE62AAE; Fri, 24 Jun 2005 09:41:20 +0930 (CST) Date: Fri, 24 Jun 2005 09:41:20 +0930 From: Mark Smith To: Tim Chown Message-Id: <20050624094120.00fff59a.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050623160126.GS20820@login.ecs.soton.ac.uk> References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> <1119538004.6872.57.camel@galen.zko.hp.com> <20050624002317.2be54643.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050623160126.GS20820@login.ecs.soton.ac.uk> 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 On Thu, 23 Jun 2005 17:01:26 +0100 Tim Chown wrote: > On Fri, Jun 24, 2005 at 12:23:17AM +0930, Mark Smith wrote: > > > > I'd think ULAs and globals deployed in parallel would be the most common > > case, so I'd think it should just work "out of the box" without having > > to tweak anything. Without putting a bit of effort into it i.e. off the > > top of my head, I can't think of scenarios where ULAs wouldn't be > > deployed in parallel with globals. > > There is the intermittently connected network, that uses ULAs internally, > but will also use globals when connected externally and multi-addressed, > but then drop back to ULA-only when its uplink disappears again. > > An example might be a community wireless network, where ADSL uplinks may be > advertised and removed over time. > I agree, "deployed" was probably the wrong word to use. 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 Sat Jun 25 18:40:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmJJo-0002Ei-Dv; Sat, 25 Jun 2005 18:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmJJl-0002EW-C0 for ipv6@megatron.ietf.org; Sat, 25 Jun 2005 18:40:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13930 for ; Sat, 25 Jun 2005 18:40:02 -0400 (EDT) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmJia-0002jJ-8o for ipv6@ietf.org; Sat, 25 Jun 2005 19:05:44 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5PMdtLC325380 for ; Sat, 25 Jun 2005 22:39:55 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5PMdthU231936 for ; Sat, 25 Jun 2005 23:39:55 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5PMdtQt017232 for ; Sat, 25 Jun 2005 23:39:55 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j5PMds41017229; Sat, 25 Jun 2005 23:39:55 +0100 Received: from zurich.ibm.com (sig-9-145-135-100.de.ibm.com [9.145.135.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA28474; Sun, 26 Jun 2005 00:39:53 +0200 Message-ID: <42BDDD38.8000204@zurich.ibm.com> Date: Sun, 26 Jun 2005 00:39:52 +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: Stig Venaas References: <20050623114323.GF15500@login.ecs.soton.ac.uk> <1119535416.6872.50.camel@galen.zko.hp.com> <20050623140947.GH17928@storhaugen.uninett.no> <1119538004.6872.57.camel@galen.zko.hp.com> <20050623150201.GM17928@storhaugen.uninett.no> In-Reply-To: <20050623150201.GM17928@storhaugen.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Vlad Yasevich , ipv6@ietf.org Subject: Re: ULAs, multicast and RFC3484 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 Stig Venaas wrote: > On Thu, Jun 23, 2005 at 10:46:44AM -0400, Vlad Yasevich wrote: > >>On Thu, 2005-06-23 at 16:09 +0200, Stig Venaas wrote: >> >>>On Thu, Jun 23, 2005 at 10:03:36AM -0400, Vlad Yasevich wrote: >>> >>>>Tim >>>> >>>>Wouldn't an update to a policy table be enough to resolve the problem? >>> >>>Yes, but isn't it best that the default policy does the right thing? >>> >> >>I agree. Is this something that may be mentioned in ULA spec? > > > Too late I think, it's already in rfc ed queue. However 3484 should be > updated anyway to remove site-locals and something about ULA could then > be added. This would be a trivial change. Yes, the problem is in 3484, so let's fix 3484 rather than further delay ULAs. > > Note that the ULA draft, draft-ietf-ipv6-unique-local-addr-09.txt is > vague regarding scopes: > > - In practice, applications may treat these addresses like global > scoped addresses. > > which I think is wrong if host also has normal global unicast > addresses. But wording indicates that they are not really global > scoped addresses. No it doesn't. It's a lower case "may" not a normative MAY - it means in plain English exactly what it says. > > Also > > 3.3 Scope Definition > > By default, the scope of these addresses is global. That is, they > are not limited by ambiguity like the site-local addresses defined in > [ADDARCH]. Rather, these prefixes are globally unique, and as such, > their applicability is greater than site-local addresses. Their > limitation is in the routability of the prefixes, which is limited to > a site and any explicit routing agreements with other sites to > propagate them (also see section 4.1). Also, unlike site-locals, a > site may have more than one of these prefixes and use them at the > same time. > > What does default mean here? It might have been better to remove the words "By default." The reality is that they are scoped by the routing setup, not by a formal scope. And so they could only be used for sourcing multicasts that will be similarly scoped by the routing setup. Clearly, 3484 defaults can't deal with that. Brian > > Stig > > >>>Else everyone with ULA doing global multicast will need to update their >>>policies. Of course vendors could use their own default policy that is >>>different from 3484's policy... >> >>Yes. I've always considered policy from 3484 an example that will be >>modified by the end-user. That's why it's there. It gives a really >>basic default. If you want to be multiaddresses with ULA and global >>prefixes, you need to tweak things. >> >>-vlad >> >> >> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sun Jun 26 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 1DmOJz-0004eI-MZ; Sun, 26 Jun 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 1DmOJx-0004e8-Tt for ipv6@megatron.ietf.org; Sun, 26 Jun 2005 00:00:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03346 for ; Sun, 26 Jun 2005 00:00:35 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmOin-0000o0-PZ for ipv6@ietf.org; Sun, 26 Jun 2005 00:26:20 -0400 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 08C14487 for ; Sun, 26 Jun 2005 00:00:16 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 26 Jun 2005 00:00:15 -0400 Message-Id: <20050626040016.08C14487@cyteen.hactrn.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 23.53% | 4 | 24.60% | 19083 | ipng@69706e6720323030352d30312d31340a.nosense.org 17.65% | 3 | 16.90% | 13109 | vladislav.yasevich@hp.com 17.65% | 3 | 16.34% | 12675 | tjc@ecs.soton.ac.uk 11.76% | 2 | 14.01% | 10864 | stig.venaas@uninett.no 11.76% | 2 | 10.80% | 8375 | mkt@ecs.soton.ac.uk 5.88% | 1 | 9.14% | 7091 | brc@zurich.ibm.com 5.88% | 1 | 4.52% | 3508 | sra+ipng@hactrn.net 5.88% | 1 | 3.68% | 2853 | bob.hinden@nokia.com --------+------+--------+----------+------------------------ 100.00% | 17 |100.00% | 77558 | 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 Jun 26 22:17:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmjBx-0000Cr-2w; Sun, 26 Jun 2005 22:17:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmjBu-0000Cg-Th for ipv6@megatron.ietf.org; Sun, 26 Jun 2005 22:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05647 for ; Sun, 26 Jun 2005 22:17:37 -0400 (EDT) Received: from yue.linux-ipv6.org ([203.178.140.15] helo=yue.st-paulia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmjat-0006gN-JW for ipv6@ietf.org; Sun, 26 Jun 2005 22:43:34 -0400 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8840D33CC2; Mon, 27 Jun 2005 11:17:53 +0900 (JST) Date: Mon, 27 Jun 2005 11:17:47 +0900 (JST) Message-Id: <20050627.111747.56360354.yoshfuji@linux-ipv6.org> To: ipv6@ietf.org, Erik.Nordmark@sun.com, jinmei@isl.rdc.toshiba.co.jp From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI/WIDE Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: yoshfuji@linux-ipv6.org, rfc-editor@rfc-editor.org Subject: Bug in RFC3542 (Advanced API) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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. Erik, Tatuya, and folks: In Page 47, Section 11.3 (Path MTU Discovery and UDP), RFC 3542 (Advanced Sockets API for IPv6) says: | This cmsghdr will be passed to every socket that sets the | IPV6_RECVPATHMTU socket option, even if the socket is non-connected. | Note that this also means an application that sets the option may | receive an IPV6_MTU ancillary data item for each ICMP too big error ~~~~~~~~ | the node receives, including such ICMP errors caused by other | applications on the node. Thus, an application that wants to perform I believe that IPV6_MTU should be IPV6_PATHMTU. -- __ /// YOSHIFUJI Hideaki, Ph.D @ USAGI/WIDE Project /. \ E-Mail: yoshfuji@linux-ipv6.org \__/ GPG-FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 27 07:41:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmrzG-00066j-Dg; Mon, 27 Jun 2005 07:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmrzF-00066e-0S for ipv6@megatron.ietf.org; Mon, 27 Jun 2005 07:41:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09822 for ; Mon, 27 Jun 2005 07:41:11 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmsOM-0000Qh-S7 for ipv6@ietf.org; Mon, 27 Jun 2005 08:07:12 -0400 Received: by wproxy.gmail.com with SMTP id i23so363880wra for ; Mon, 27 Jun 2005 04:41:02 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=N700YUC1ibOSbV92qN/foG+aLeOMAz10Bv8lQw4w5PR4LY22l2MCzS3F0wGSDiCDEci9ff8qTyW58HxdD5T6Uzv2/rvG3SS7QGzhtoQXcBmfxBdqeIqitDvqFVzEKS44TlWxzy+oJI45P4NpE3mHKMdPa/lq0Rbs3AGa5AbETW8= Received: by 10.54.50.44 with SMTP id x44mr3405984wrx; Mon, 27 Jun 2005 04:41:01 -0700 (PDT) Received: by 10.54.101.15 with HTTP; Mon, 27 Jun 2005 04:41:01 -0700 (PDT) Message-ID: Date: Mon, 27 Jun 2005 17:11:01 +0530 From: Srinivas Goud To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: IPv6 Extension Headers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Srinivas Goud List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello All, I am a beginner and working on IPv6 Extension Headers Implementation for IP= Sec. I am confused with freeBSD implementation and RFC2460 specification for Destination Options. My interpretation from RFC2460 is that, If a packet consists of hop-by-hop and destination extension headers, destination header should be inserted inside AH. i.e., hop + AH + dst. But freeBSD implementation is the other way, i.e., hop + dst + AH. which is the correct way of implementation according to RFC2460? Please let me know, if my interpretation is wrong. Any help/suggestion is greatly appreciated. Regards, Srinivas. --=20 Srinivas Goud "Everything is Nicer when shared with a Friend" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 27 08:24:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmseg-00053K-Mq; Mon, 27 Jun 2005 08:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmsef-00053F-3d for ipv6@megatron.ietf.org; Mon, 27 Jun 2005 08:24:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14060 for ; Mon, 27 Jun 2005 08:23:59 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmt3m-00034N-6F for ipv6@ietf.org; Mon, 27 Jun 2005 08:50:00 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j5RCNAN07291; Mon, 27 Jun 2005 14:23:11 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j5RCNA52016391; Mon, 27 Jun 2005 14:23:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506271223.j5RCNA52016391@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Srinivas Goud In-reply-to: Your message of Mon, 27 Jun 2005 17:11:01 +0530. Date: Mon, 27 Jun 2005 14:23:10 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipv6@ietf.org Subject: Re: IPv6 Extension Headers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: I am a beginner and working on IPv6 Extension Headers Implementation for IPSec. I am confused with freeBSD implementation and RFC2460 specification for Destination Options. => RFC 2460 is not complete about positions of destination options My interpretation from RFC2460 is that, If a packet consists of hop-by-hop and destination extension headers, destination header should be inserted inside AH. i.e., hop + AH + dst. But freeBSD implementation is the other way, i.e., hop + dst + AH. => this is the correct way if (and only if) the destination option is a home address option. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 27 08:52:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmt6b-0002mA-I0; Mon, 27 Jun 2005 08:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmroe-00040E-BR for ipv6@megatron.ietf.org; Mon, 27 Jun 2005 07:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09037 for ; Mon, 27 Jun 2005 07:30:14 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmsDl-000617-TI for ipv6@ietf.org; Mon, 27 Jun 2005 07:56:15 -0400 Received: by wproxy.gmail.com with SMTP id i24so368225wra for ; Mon, 27 Jun 2005 04:30:02 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=Wk/u6BYxxqNrTKESKqASQN32DrCraYV1p67qHgufNKT6t9iJc44NhU/isKirI3bIc+1OxXNF/3z3ZNRJU2JKbEOrIfH8ikX1HL4Dl/5WnUnOp0j5MvN8DBrz6OphbC7EXiA65ROw0Bh1QfpWq1WeXchKrg/M9h5ZLDh68k5FlLw= Received: by 10.54.15.15 with SMTP id 15mr1059620wro; Mon, 27 Jun 2005 04:30:02 -0700 (PDT) Received: by 10.54.101.15 with HTTP; Mon, 27 Jun 2005 04:30:02 -0700 (PDT) Message-ID: Date: Mon, 27 Jun 2005 17:00:02 +0530 From: Srinivas Goud To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 27 Jun 2005 08:52:45 -0400 Subject: IPv6 Extension Headers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Srinivas Goud List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hello All, I am working on IPv6 Extension Headers Implementation for IPSec. I am confused with freeBSD implementation and RFC2460 specification for Destination Options. My interpretation from RFC2460 is that, If a packet consists of hop-by-hop and destination extension headers, destination header should be inserted inside AH. i.e., hop + AH + dst. But freeBSD implementation is the other way, i.e., hop + dst + AH. which is the correct way of implementation according to RFC2460? Please let me know, if my interpretation is wrong. Any help/suggestion is greatly appreciated. Regards, Srinivas. --=20 Srinivas Goud "Everything is Nicer when shared with a Friend" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Jun 27 16:00:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzmn-0001Sb-3M; Mon, 27 Jun 2005 16:00:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzml-0001SM-OP for ipv6@megatron.ietf.org; Mon, 27 Jun 2005 16:00:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02734 for ; Mon, 27 Jun 2005 16:00:49 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn0Bx-0002TZ-MG for ipv6@ietf.org; Mon, 27 Jun 2005 16:26:55 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:49c6:114:c810:409d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 10E321521A; Tue, 28 Jun 2005 05:04:45 +0900 (JST) Date: Tue, 28 Jun 2005 05:00:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050627.111747.56360354.yoshfuji@linux-ipv6.org> References: <20050627.111747.56360354.yoshfuji@linux-ipv6.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Erik.Nordmark@sun.com, ipv6@ietf.org, rfc-editor@rfc-editor.org Subject: Re: Bug in RFC3542 (Advanced API) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP 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, 27 Jun 2005 11:17:47 +0900 (JST), >>>>> YOSHIFUJI Hideaki said: > In Page 47, Section 11.3 (Path MTU Discovery and UDP), > RFC 3542 (Advanced Sockets API for IPv6) says: > | This cmsghdr will be passed to every socket that sets the > | IPV6_RECVPATHMTU socket option, even if the socket is non-connected. > | Note that this also means an application that sets the option may > | receive an IPV6_MTU ancillary data item for each ICMP too big error > ~~~~~~~~ > | the node receives, including such ICMP errors caused by other > | applications on the node. Thus, an application that wants to perform > I believe that IPV6_MTU should be IPV6_PATHMTU. You're right. Thanks for reporting the error. RFC editor, could you add this report to the RFC errata page? 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 Tue Jun 28 00:59:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn8CL-0001sH-IM; Tue, 28 Jun 2005 00:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn8CJ-0001s8-2S for ipv6@megatron.ietf.org; Tue, 28 Jun 2005 00:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05969 for ; Tue, 28 Jun 2005 00:59:43 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.198]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn8ba-0000Lx-36 for ipv6@ietf.org; Tue, 28 Jun 2005 01:25:55 -0400 Received: by wproxy.gmail.com with SMTP id i22so566939wra for ; Mon, 27 Jun 2005 21:59:31 -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=aSgX72LhZ2Fe+9chE2HGXNgrWwMG4dl0J7qsu4xAONlMKq0R23LuL28UlBI+I5laEe+/rp98ZzGFXecpTDdEEvSQIS8I6nAobiCokvVo/w5EEcGR66enHJ3b0raJ3RI7I00xG1zEolDwJGq70ioPqZvjohF41Qv+oq7AbP9zuPw= Received: by 10.54.40.48 with SMTP id n48mr3958802wrn; Mon, 27 Jun 2005 21:59:31 -0700 (PDT) Received: by 10.54.101.15 with HTTP; Mon, 27 Jun 2005 21:59:31 -0700 (PDT) Message-ID: Date: Tue, 28 Jun 2005 10:29:31 +0530 From: Srinivas Goud To: Francis Dupont In-Reply-To: <200506271223.j5RCNA52016391@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200506271223.j5RCNA52016391@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: IPv6 Extension Headers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Srinivas Goud List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Francis, I have some more queries about RFC2460, Please let me know the insertion of AH in the following cases: from RFC2460: (section 4.1) Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). 1. hop + dst (you have clarified in previous mail= ) 2. hop + dst + route (let me know AH insertion place) 3. hop + dst + route + dst (let me know AH insertion place) from RFC2460: (section 4.1) IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. 1. hop + dst + dst (let me know AH insertion place) 2. hop + dst + dst + route + route (let me know AH insertion place) 3. hop + dst + dst + route + route + dst + dst (let me know AH insertion place) 4. hop + dst + route + dst + dst + route + dst + dst (let me know AH insertion place) Any help/suggestion is greatly appreciated. Regards, Srinivas. On 6/27/05, Francis Dupont wrote: > In your previous mail you wrote: >=20 > I am a beginner and working on IPv6 Extension Headers Implementation f= or IPSec. > I am confused with freeBSD implementation and RFC2460 specification > for Destination Options. >=20 > =3D> RFC 2460 is not complete about positions of destination options >=20 > My interpretation from RFC2460 is that, If a packet consists of > hop-by-hop and destination extension headers, destination header > should be inserted inside AH. > i.e., hop + AH + dst. >=20 > But freeBSD implementation is the other way, > i.e., hop + dst + AH. >=20 > =3D> this is the correct way if (and only if) the destination option > is a home address option. >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 --=20 Srinivas Goud "Everything is Nicer when shared with a Friend" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 28 08:26:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFAP-0008Sk-D6; Tue, 28 Jun 2005 08:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFAO-0008SY-7n for ipv6@megatron.ietf.org; Tue, 28 Jun 2005 08:26:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01248 for ; Tue, 28 Jun 2005 08:26:14 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnFZj-0004bI-Fr for ipv6@ietf.org; Tue, 28 Jun 2005 08:52:27 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j5SCPma17335; Tue, 28 Jun 2005 14:25:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j5SCPmj4021834; Tue, 28 Jun 2005 14:25:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506281225.j5SCPmj4021834@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Srinivas Goud In-reply-to: Your message of Tue, 28 Jun 2005 10:29:31 +0530. Date: Tue, 28 Jun 2005 14:25:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ipv6@ietf.org Subject: Re: IPv6 Extension Headers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org In your previous mail you wrote: Hi Francis, I have some more queries about RFC2460, Please let me know the insertion of AH in the following cases: from RFC2460: (section 4.1) Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). => in fact the destination options header can occur three times. 1. hop + dst (you have clarified in previous mail) 2. hop + dst + route (let me know AH insertion place) 3. hop + dst + route + dst (let me know AH insertion place) from RFC2460: (section 4.1) IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. => look at the RFC 3775! 1. hop + dst + dst (let me know AH insertion place) 2. hop + dst + dst + route + route (let me know AH insertion place) 3. hop + dst + dst + route + route + dst + dst (let me know AH insertion place) 4. hop + dst + route + dst + dst + route + dst + dst (let me know AH insertion place) Any help/suggestion is greatly appreciated. => in fact you have to look at the destination options: - if they apply to intermediate destination the header must be before the first routing header and after if there is one the hop-by-hop header, and AH is always after the last routing header. - home address option must be after the last routing header if there is one, and before the fragmentation header if there is one. AH is always after the fragmentation header. - options for the final destination must be after any IPsec header if there is one, and before the upper layer and final (i.e., not extension) header. So AH is always before this kind of destination options header. The only case I don't know if it should supported is where options for intermediate destionations and multiple routing headers are mixed. BTW this case should not happen with current registered destination options and routing header types... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Tue Jun 28 08:46:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFUE-00050Y-NW; Tue, 28 Jun 2005 08:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFUA-0004yw-CH for ipv6@megatron.ietf.org; Tue, 28 Jun 2005 08:46:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03539 for ; Tue, 28 Jun 2005 08:46:40 -0400 (EDT) Message-Id: <200506281246.IAA03539@ietf.org> Received: from [202.108.45.160] (helo=126.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnFtG-0006dJ-LK for ipv6@ietf.org; Tue, 28 Jun 2005 09:12:50 -0400 Received: from thinker (unknown [202.115.28.189]) by smtp3 (Coremail) with SMTP id Q4IlVplGwUKF31Er.1 for ; Tue, 28 Jun 2005 20:46:20 +0800 (CST) X-Originating-IP: [202.115.28.189] Date: Tue, 28 Jun 2005 20:46:13 +0800 From: "QinKe" To: "ipv6" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: a silly 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="===============0993897248==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0993897248== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBhbGw6DQoNCkkgYW0gYSBub3ZpY2UgYWJvdXQgSVBzZWMuIE5vdyBJIGhhdmUgYSBzaWxs eSBxdWVzdGlvbi4gQXMgd2Uga25vdywgdGhlIE1UVSBvZiBFdGhlcm5ldCBpcyAxNTAwLiBJUHNl YyB3aWxsIGFkZCBhZGRpdGlvbmFsIGhlYWRlcnMgdG8gSVAgcGFja2V0LiBJZiBhIHBhY2tldCdz IHNpemUgaXMganVzdCAxNTAwLCB0aGVuIGhvdyB3aWxsIElQc2VjIGRlYWwgd2l0aCBzdWNoIG9j Y2FzaW9uPyBUaGUgcGFja2V0J3Mgc2l6ZSB3aWxsIGxhcmdlciB0aGFuIDE1MDAgYWZ0ZXIgc29t ZSBoZWFkZXJzIGFyZSBhZGRlZC4gU28gZnJhZ21lbnRhdGlvbiBpcyBuZWVkZWQgaGVyZS4gQnV0 IG9uIHRoZSBvdGhlciBoYW5kLCBJUHY2IHJvdXRlcnMgY2FuJ3QgZG8gZnJhZ21lbnRhdGlvbi4g U28gSSBhbSBpbiBjb25mdXNpb24uDQoNCkJlc3QgcmVnYXJkcw0KoaGhoaGhoaGhoaGhoaGhoQ0K oaGhoaGhoaGhoaGhoaGhoXl1eHVhbnFrQDEyNi5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAw NS0wNi0yOA0K --===============0993897248== 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 -------------------------------------------------------------------- --===============0993897248==-- From ipv6-bounces@ietf.org Tue Jun 28 09:12:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFtM-0004no-Ta; Tue, 28 Jun 2005 09:12:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFtL-0004nj-8H for ipv6@megatron.ietf.org; Tue, 28 Jun 2005 09:12:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06228 for ; Tue, 28 Jun 2005 09:12:41 -0400 (EDT) Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnGIg-0001B4-GR for ipv6@ietf.org; Tue, 28 Jun 2005 09:38:55 -0400 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E41D58370; Tue, 28 Jun 2005 15:12:19 +0200 (CEST) From: Jeroen Massar To: QinKe In-Reply-To: <200506281246.IAA03539@ietf.org> References: <200506281246.IAA03539@ietf.org> Organization: Unfix Date: Tue, 28 Jun 2005 15:12:15 +0200 Message-Id: <1119964335.31524.1.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ipv6 Subject: Re: a silly 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="===============2126841970==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============2126841970== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-y8W+Pc2iw7hOqcvY82Hz" --=-y8W+Pc2iw7hOqcvY82Hz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-06-28 at 20:46 +0800, QinKe wrote: > Dear all: >=20 > I am a novice about IPsec. Now I have a silly question. > As we know, the MTU of Ethernet is 1500. IPsec will add additional > headers to IP packet. If a packet's size is just 1500, then how will > IPsec deal with such occasion? The packet's size will larger than 1500 > after some headers are added. So fragmentation is needed here. > But on the other hand, IPv6 routers can't do fragmentation. So I am in co= nfusion. In this case the first router, actually the machine itself (localhost/loopback) will notify, the sender, itself, that the packet is too big. The host stack notices this and will start fragmenting. The on-the-path routers will never fragment. Greets, Jeroen --=-y8W+Pc2iw7hOqcvY82Hz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCwUyvKaooUjM+fCMRAoF/AJsFh9Nq/ka4zE+669L15qT0rHmKPwCgo1hS 5tzpyjAlooqkNGE7FW4SybY= =DvC9 -----END PGP SIGNATURE----- --=-y8W+Pc2iw7hOqcvY82Hz-- --===============2126841970== 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 -------------------------------------------------------------------- --===============2126841970==-- From ipv6-bounces@ietf.org Wed Jun 29 03:47:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnXIO-0006wo-Kn; Wed, 29 Jun 2005 03: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 1DnXIM-0006wg-HL for ipv6@megatron.ietf.org; Wed, 29 Jun 2005 03:47:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19616 for ; Wed, 29 Jun 2005 03:47:41 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnXhs-0005Nc-KE for ipv6@ietf.org; Wed, 29 Jun 2005 04:14:04 -0400 Received: by wproxy.gmail.com with SMTP id i24so773718wra for ; Wed, 29 Jun 2005 00:47:33 -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=Gz0LL+UNVvjJWcTfe9h/9GzKFo0rBlaaQosWP0wX28/0KTXRbyY333lBlWy7FsNnB9Pn8loZdhIfWWOjrg6CbcehJ0CxlSrTx4keRKDAnm7Ns0YHuV2CahbE64ImIC/FOjVdFUlcIKmN/XmyrcNnPkuxOjNSUXjgDIYjsVMEKuI= Received: by 10.54.38.58 with SMTP id l58mr51899wrl; Wed, 29 Jun 2005 00:47:33 -0700 (PDT) Received: by 10.54.101.15 with HTTP; Wed, 29 Jun 2005 00:47:33 -0700 (PDT) Message-ID: Date: Wed, 29 Jun 2005 13:17:33 +0530 From: Srinivas Goud To: Francis Dupont In-Reply-To: <200506281225.j5SCPmj4021834@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200506281225.j5SCPmj4021834@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: Re: IPv6 Extension Headers X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Srinivas Goud List-Id: "IP Version 6 Working Group \(ipv6\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org Hi Francis,=20 Thank you very much for the information. I am proceeding with the implementation. How do we distinguish the destination options?=20 (intermediate destination / home address destination / final destination) As per my understanding intermediate destination is the one which is coming before routing header and final destination is the one which is coming after routing header. Is my understanding correct? =20 I am not having clear idea about home address option. Regards, Srinivas. On 6/28/05, Francis Dupont wrote: > In your previous mail you wrote: >=20 > Hi Francis, > I have some more queries about RFC2460, Please let me know the > insertion of AH in the following cases: >=20 > from RFC2460: (section 4.1) > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). >=20 > =3D> in fact the destination options header can occur three times. >=20 > 1. hop + dst (you have clarified in previous= mail) > 2. hop + dst + route (let me know AH insertion place) > 3. hop + dst + route + dst (let me know AH insertion place) >=20 >=20 > from RFC2460: (section 4.1) > IPv6 nodes must accept and attempt to process extension headers in > any order and occurring any number of times in the same packet, > except for the Hop-by-Hop Options header which is restricted to > appear immediately after an IPv6 header only. Nonetheless, it is > strongly advised that sources of IPv6 packets adhere to the above > recommended order until and unless subsequent specifications revise > that recommendation. >=20 > =3D> look at the RFC 3775! >=20 > 1. hop + dst + dst (let > me know AH insertion place) > 2. hop + dst + dst + route + route (let me > know AH insertion place) > 3. hop + dst + dst + route + route + dst + dst (let me know > AH insertion place) > 4. hop + dst + route + dst + dst + route + dst + dst (let me know AH > insertion place) >=20 > Any help/suggestion is greatly appreciated. >=20 > =3D> in fact you have to look at the destination options: > - if they apply to intermediate destination the header must be before > the first routing header and after if there is one the hop-by-hop head= er, > and AH is always after the last routing header. > - home address option must be after the last routing header if there is = one, > and before the fragmentation header if there is one. AH is always afte= r > the fragmentation header. > - options for the final destination must be after any IPsec header if th= ere > is one, and before the upper layer and final (i.e., not extension) hea= der. > So AH is always before this kind of destination options header. > The only case I don't know if it should supported is where options for > intermediate destionations and multiple routing headers are mixed. BTW > this case should not happen with current registered destination options > and routing header types... >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 --=20 Srinivas Goud "Everything is Nicer when shared with a Friend" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Jun 29 14:52:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnhfe-0007Pm-Je; Wed, 29 Jun 2005 14:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnhfc-0007Ph-2a for ipv6@megatron.ietf.org; Wed, 29 Jun 2005 14:52:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23783 for ; Wed, 29 Jun 2005 14:52:22 -0400 (EDT) From: Mukesh.K.Gupta@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dni5C-0002OH-Sg for ipv6@ietf.org; Wed, 29 Jun 2005 15:18:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5TIlcdZ002213; Wed, 29 Jun 2005 21:47:38 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 21:51:59 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 13:51:57 -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: Wed, 29 Jun 2005 13:51:56 -0500 Message-ID: <2334E6CC5C1FD34F90C1167EA4EBFE5B56C6C0@daebe102.NOE.Nokia.com> Thread-Topic: a silly question Thread-Index: AcV75GDfvL7c4fLkQfOptPAnGSBqdwA9rnKg To: , X-OriginalArrivalTime: 29 Jun 2005 18:51:57.0421 (UTC) FILETIME=[A003C1D0:01C57CDB] X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org Subject: RE: a silly 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 If the router that is doing IPsec is a VPN gateway performing IPsec in tunnel mode, it can do fragmentation after adding IPsec headers to it. In this case, the IPsec gateway is re-originating the packet and as a originator, it can fragment the packets. A <--> B <=3D=3D=3D=3D=3D=3D=3D> C <---> D [A is talking to D. B and C are doing IPsec in tunnel mode] In this case, I think, B can fragment the packets if needed after encapsulating the packets inside another IPv6 packet. - Mukesh -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of ext Jeroen Massar Sent: Tuesday, June 28, 2005 6:12 AM To: QinKe Cc: ipv6 Subject: Re: a silly question On Tue, 2005-06-28 at 20:46 +0800, QinKe wrote: > Dear all: >=20 > I am a novice about IPsec. Now I have a silly question. > As we know, the MTU of Ethernet is 1500. IPsec will add additional > headers to IP packet. If a packet's size is just 1500, then how will > IPsec deal with such occasion? The packet's size will larger than 1500 > after some headers are added. So fragmentation is needed here. > But on the other hand, IPv6 routers can't do fragmentation. So I am in = confusion. In this case the first router, actually the machine itself (localhost/loopback) will notify, the sender, itself, that the packet is too big. The host stack notices this and will start fragmenting. The on-the-path routers will never fragment. Greets, Jeroen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 30 00:31:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnqhz-0002V2-QJ; Thu, 30 Jun 2005 00:31:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnqhx-0002Ux-KA for ipv6@megatron.ietf.org; Thu, 30 Jun 2005 00:31:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07457 for ; Thu, 30 Jun 2005 00:31:22 -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 1Dnr7d-0005fU-Kc for ipv6@ietf.org; Thu, 30 Jun 2005 00:57:58 -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 <0IIV00B4VRDIY5@szxga01-in.huawei.com> for ipv6@ietf.org; Thu, 30 Jun 2005 12:34:30 +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 <0IIV00ENIRC979@szxga01-in.huawei.com> for ipv6@ietf.org; Thu, 30 Jun 2005 12:34:30 +0800 (CST) Received: from c03731 ([10.110.90.77]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IIV002KAPWGRM@szxml01-in.huawei.com>; Thu, 30 Jun 2005 12:02:41 +0800 (CST) Date: Thu, 30 Jun 2005 11:54:26 +0800 From: chenhongfei In-reply-to: <2334E6CC5C1FD34F90C1167EA4EBFE5B56C6C0@daebe102.NOE.Nokia.com> To: Mukesh.K.Gupta@nokia.com, jeroen@unfix.org, yuxuanqk@126.com Message-id: <000001c57d27$69061510$4d5a6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 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: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7BIT Cc: ipv6@ietf.org Subject: RE: a silly 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 Hi The algorithm of fragment in RFC2893 described the rule of fragment in 6o4 tunnel. In this algorithm, there are four results. The result C is not fragment if (ipv4 mtu -20) is larger than 1280 and packet is larger than (IPv4 path MTU - 20). So I think in this case, B should judge the MTU of output port which between B and C. Because minimum MTU is 1280 in ipv6, so B should Send IPv6 ICMP "packet too big" and Drop packet if packets adding IPsec headers is larger then the MTU of output port. Do you agree? if (IPv4 path MTU - 20) is less than or equal to 1280 if packet is larger than 1280 bytes result A Send IPv6 ICMP "packet too big" with MTU = 1280. Drop packet. else result B Encapsulate but do not set the Don't Fragment flag in the IPv4 header. The resulting IPv4 packet might be fragmented by the IPv4 layer on the encapsulating node or by some router along the IPv4 path. endif else if packet is larger than (IPv4 path MTU - 20) result C Send IPv6 ICMP "packet too big" with MTU = (IPv4 path MTU - 20). Drop packet. else result D Encapsulate and set the Don't Fragment flag in the IPv4 header. endif endif Best regards Hongfei Chen -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Mukesh.K.Gupta@nokia.com Sent: Thursday, June 30, 2005 2:52 AM To: jeroen@unfix.org; yuxuanqk@126.com Cc: ipv6@ietf.org Subject: RE: a silly question If the router that is doing IPsec is a VPN gateway performing IPsec in tunnel mode, it can do fragmentation after adding IPsec headers to it. In this case, the IPsec gateway is re-originating the packet and as a originator, it can fragment the packets. A <--> B <=======> C <---> D [A is talking to D. B and C are doing IPsec in tunnel mode] In this case, I think, B can fragment the packets if needed after encapsulating the packets inside another IPv6 packet. - Mukesh -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org]On Behalf Of ext Jeroen Massar Sent: Tuesday, June 28, 2005 6:12 AM To: QinKe Cc: ipv6 Subject: Re: a silly question On Tue, 2005-06-28 at 20:46 +0800, QinKe wrote: > Dear all: > > I am a novice about IPsec. Now I have a silly question. > As we know, the MTU of Ethernet is 1500. IPsec will add additional > headers to IP packet. If a packet's size is just 1500, then how will > IPsec deal with such occasion? The packet's size will larger than 1500 > after some headers are added. So fragmentation is needed here. > But on the other hand, IPv6 routers can't do fragmentation. So I am in confusion. In this case the first router, actually the machine itself (localhost/loopback) will notify, the sender, itself, that the packet is too big. The host stack notices this and will start fragmenting. The on-the-path routers will never fragment. Greets, Jeroen -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Jun 30 05:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnuum-0005B3-Iy; Thu, 30 Jun 2005 05:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnuui-0005As-BY for ipv6@megatron.ietf.org; Thu, 30 Jun 2005 05:00:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18014 for ; Thu, 30 Jun 2005 05:00:50 -0400 (EDT) Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnvKQ-0003gy-Fx for ipv6@ietf.org; Thu, 30 Jun 2005 05:27:27 -0400 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 47EB38370; Thu, 30 Jun 2005 11:00:28 +0200 (CEST) From: Jeroen Massar To: Mukesh.K.Gupta@nokia.com In-Reply-To: <2334E6CC5C1FD34F90C1167EA4EBFE5B56C6C0@daebe102.NOE.Nokia.com> References: <2334E6CC5C1FD34F90C1167EA4EBFE5B56C6C0@daebe102.NOE.Nokia.com> Organization: Unfix Date: Thu, 30 Jun 2005 11:00:24 +0200 Message-Id: <1120122024.10492.49.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipv6@ietf.org, yuxuanqk@126.com Subject: RE: a silly 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="===============0038146163==" Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org --===============0038146163== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dA9H9fxvy9AguHhYn2cD" --=-dA9H9fxvy9AguHhYn2cD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-06-29 at 13:51 -0500, Mukesh.K.Gupta@nokia.com wrote: > If the router that is doing IPsec is a VPN gateway performing > IPsec in tunnel mode, it can do fragmentation after adding IPsec > headers to it. In this case, the IPsec gateway is re-originating > the packet and as a originator, it can fragment the packets. Ack, that is another way to solve this issue. The trick is that a router does not have to do it, and really should not be doing it, but of course it could do fragmentation if they want to do it. Greets, Jeroen --=-dA9H9fxvy9AguHhYn2cD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCw7SoKaooUjM+fCMRAj2CAJ91WhHCGvxKczFibC22wqesMLYYRgCfa4wS fPBtDeqsH8p5OSVr4QChI8s= =/aJu -----END PGP SIGNATURE----- --=-dA9H9fxvy9AguHhYn2cD-- --===============0038146163== 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 -------------------------------------------------------------------- --===============0038146163==-- From ipv6-bounces@ietf.org Thu Jun 30 18:50:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7rg-0003CM-KU; Thu, 30 Jun 2005 18:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7rE-00034k-4i; Thu, 30 Jun 2005 18:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02742; Thu, 30 Jun 2005 18:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do8H2-0007gP-OZ; Thu, 30 Jun 2005 19:16:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Do7r8-0002Py-K7; Thu, 30 Jun 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 30 Jun 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ipv6@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-host-load-sharing-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 : IPv6 Host to Router Load Sharing Author(s) : R. Hinden, D. Thaler Filename : draft-ietf-ipv6-host-load-sharing-04.txt Pages : 6 Date : 2005-6-30 The original IPv6 conceptual sending algorithm does not do load- sharing among equivalent IPv6 routers, and suggests schemes which can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-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-host-load-sharing-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-host-load-sharing-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-6-30170818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-host-load-sharing-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-host-load-sharing-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-30170818.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--