From kauer@biplane.com.au Wed Aug 1 03:14:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF021F870A for ; Wed, 1 Aug 2012 03:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61eUEa2puQnq for ; Wed, 1 Aug 2012 03:14:28 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 4803121F8709 for ; Wed, 1 Aug 2012 03:14:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACYAGVCWZX+7/2dsb2JhbAANOIV7tkcBAQEEI1YQCxgqAgJXBhOwXG6TNotjBoVXgRIDoFSHcYFEAQUD Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 01 Aug 2012 19:44:22 +0930 Subject: Re: about DHCPv6/SLAAC interaction From: Karl Auer To: IETF IPv6 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AqvE2HEytg7Dql4bkBkp" Date: Wed, 01 Aug 2012 20:14:17 +1000 Message-ID: <1343816057.26898.384.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 10:14:29 -0000 --=-AqvE2HEytg7Dql4bkBkp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-08-01 at 01:06 +0000, Liubing (Leo) wrote: > You mentioned the ambiguous M flag in RA, indeed this is a problem, > and it has been disscussed in 6renum WG. >=20 > So if you're still consern about the issue, looking forward to hear > some comments from you, either on the mics or in the mail. [Leo sent me the above off list, but I post my reply here with his permission] Thanks! A host should always be allowed to do DHCPv6 in the *absence* of information to the contrary; this is no different to NOT doing DHCPv6 in the absence of information. Also, a host may be in a self-contained or isolated network, i.e., one without a router, but with a DHCP server. So NOT receiving RAs is no reason NOT to do DHCPv6. Nor is it a reason to do it either, of course - i.e., it's up to the host :-) I'll preface all this my saying that I think the M and O flags as generally implemented and used are pretty much useless. The best thing to do with them would be to deprecate them altogether. If they must be retained, then I feel that the semantics should be as follows, and as far as I can tell from the RFC, this is all allowed: The O and M flags are completely independent. The O flag implies nothing about address configuration, and the M flag implies nothing about whether ancillary information is available. Clarifying those points alone would make the RFC much more useful. A valid RA can contain both the O and the M flags. The M and O flags are advisory: - a host MAY attempt to obtain an address via DHCPv6 without seeing an RA at all. Rationale: The host may be in an isolated network, containing a DHCPv6 server, but no router. - a host MAY attempt to obtain an address via DHCPv6 even if it sees an RA with no M flag. Rationale: Not all routers are necessarily "authoritative"; there may be multiple routers on a link, not all of which are advertising an available DHCPv6 server. - a host MAY attempt to obtain ancillary information via DHCPv6 without seeing a RA at all. Rationale: The host may be in an isolated network, containing a DHCPv6 server, but no router. - a host MAY attempt to obtain ancillary information via DHCPv6 even if it sees an RA with no M flag. Rationale: Not all routers are necessarily "authoritative"; there may be multiple routers on a link, not all of which are advertising an available DHCPv6 server. Once a DHCPv6 address has been configured or ancillary info obtained: - a host MAY deconfigure a DHCPv6 address if an RA is seen that does not contain an M flag. Rationale: In the absence of any compulsory aspect to DHCPv6, the deconfiguration of addresses that were "voluntarily" acquired must logically be permitted. - a host SHOULD deconfigure a DHCPv6 address if an RA is seen that does not contain an M flag IF that address was configured in response to an M flag. Rationale: If the reason the host configured the address was because it reacted to an M flag, then it should react to the absence of M flags by deconfiguring the address. That is, the host should be consistent in its approach to the M flag. Once ancillary information has been obtained via DHCPv6: - a host MAY discard ancillary information obtained via DHCPv6 if an RA is seen that does not contain an O flag. Rationale: In the absence of any compulsory aspect to DHCPv6, the disposal of ancillary information "voluntarily" acquired must logically be permitted. - a host SHOULD discard ancillary information obtained via DHCPv6 if an RA is seen that does not contain an O flag IF that information was obtained in response to an O flag. Rationale: If the reason the host obtained ancillary information was because it reacted to an O flag, then it should react to the absence of O flags by discarding the information. That is, the host should be consistent in its approach to the O flag. The above are the "non-strict" semantics. If a stricter approach is needed, I suggest an additional flag that, if set, changes the M and O flags from advisory to prescriptive. Let's call it the DHCP_STRICT flag. The flag MUST default to FALSE. Because the *absence* of an M or O flag is meaningful in strict mode, we also need a flag that indicates whether the DHCP_STRICT flag itself is meaningful, let's call it DHCP_STRICT_MODE. This flag defaults to FALSE. If DHCP_STRICT_MODE is FALSE, then the value of the DHCP_STRICT flag is not valid and a host should use the non-strict semantics. If DHCP_STRICT_MODE is TRUE, then the value of the DHCP_STRICT flag is valid, and the following semantics apply. If DHCP_STRICT is FALSE, then a host MUST use the non-strict semantics. If DHCP_STRICT is TRUE, then a host MUST use the following semantics. The O and M flags are completely independent. The O flag implies nothing about address configuration, and the M flag implies nothing about whether ancillary information is available. A valid RA can contain both the O and the M flags. Once a host has seen an RA with DHCP_STRICT_MODE=3DTRUE and DHCP_STRICT=3DFALSE, the host MUST ignore any subsequent RA with DHCP_STRICT_MODE=3DTRUE and DHCP_STRICT=3DTRUE. A host MAY log a warning in this case. This state MUST NOT be persistently stored. Rationale: Moving from strict to non-strict is much less harmful than moving from non-strict to strict, given that strict mode can require hosts to deconfigure addresses or not acquire them in the first place. Not having this state in persistent storage means that a reset of the network stack or the host itself will clear the state, allowing it move from non-strict to strict mode. The M and O flags MUST be honoured if known: - a host MAY attempt to obtain an address via DHCPv6 without seeing an RA at all. Rationale: The host may be in an isolated network, containing a DHCPv6 server, but no router. - once it has seen an RA on a link, a host MUST NOT attempt to obtain an address via DHCPv6 unless it sees an M flag. Rationale: In strict mode, the M flag is prescriptive; no M flag =3D no DHCPv6 address configuration. - a host MAY attempt to obtain ancillary information via DHCPv6 without seeing a RA at all. Rationale: The host may be in an isolated network, containing a DHCPv6 server, but no router. - once it has seen an RA on a link, a host MUST NOT attempt to obtain ancillary information via DHCPv6 unless it sees an O flag. Rationale: In strict mode, the O flag is prescriptive; no O flag =3D no ancillary information via DHCPv6. Once a DHCPv6 address has been configured: - a host MUST deconfigure a DHCPv6 address if an RA is seen that does not contain an M flag. However, deconfiguration MUST be done by allowing the valid lifetime of the address to expire OR two hours to elapse, whichever is the lesser. Rationale: If the network is no longer advertising a DHCPv6 server, strict mode requires that hosts no longer use information obtained via DHCPv6. The delay provides some some hysteresis and also some protection against rogue RAs. Once ancillary information has been obtained via DHCPv6: - a host MAY discard ancillary information obtained via DHCPv6 if an RA is seen that does not contain an O flag. If an address has been obtained via DHCPv6, the host MUST wait and discard the ancillary information only at the next renewal of that address or after two hours, whichever is the lesser period. Rationale: If the network is no longer advertising a DHCPv6 server, strict mode requires that hosts no longer use information obtained via DHCPv6. This delay provides some hysteresis and also some protection against rogue RAs. A variant on strict mode is semi-strict, where you can specify "MUST do DHCPv6" via the M flag, but you can't specify "MUST NOT" through its absence. And mutatis mutandis for the O flag. I don't personally feel that all this is necessary. Also, I think that the security considerations relating to strict mode (and to your very similar suggestions) make them dangerous. A rogue router could issue RAs that cause hosts on a compromised link to not do DHCPv6 at all, deconfigure DHCPv6 addresses and/or discard ancillary information. For that reason I prefer the non-strict semantics. How does all this interact with SLAAC? It doesn't. If you want your hosts to do SLAAC, you set the autoconf flag; otherwise you don't. If you don't want hosts in a subnet to do DHCPv6, configure your DHCPv6 servers to not provide addresses to that subnet. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-AqvE2HEytg7Dql4bkBkp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAlAZAXMACgkQFpl7eE7uYBd6tgEAuaBCKy818Ed0rQMcS2uRHJ07 dbyUguIioC/U+GgeWFABAMs7kOOPz2ERa6Ix1XNBLRuV57SsHC6yCKnzxRhoEImy =A+sb -----END PGP SIGNATURE----- --=-AqvE2HEytg7Dql4bkBkp-- From swmike@swm.pp.se Wed Aug 1 03:21:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643C721F8575 for ; Wed, 1 Aug 2012 03:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bkCVvGk93me for ; Wed, 1 Aug 2012 03:21:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CE6B021F857D for ; Wed, 1 Aug 2012 03:21:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2610F9C; Wed, 1 Aug 2012 12:21:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 228C79A; Wed, 1 Aug 2012 12:21:31 +0200 (CEST) Date: Wed, 1 Aug 2012 12:21:31 +0200 (CEST) From: Mikael Abrahamsson To: Karl Auer Subject: Re: about DHCPv6/SLAAC interaction In-Reply-To: <1343816057.26898.384.camel@karl> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> <1343816057.26898.384.camel@karl> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 10:21:32 -0000 On Wed, 1 Aug 2012, Karl Auer wrote: > I'll preface all this my saying that I think the M and O flags as > generally implemented and used are pretty much useless. The best thing > to do with them would be to deprecate them altogether. I know of one vendor device (I'm trying to get them to change) who in presence of telling the router to advertise the M-flag, automatically removes the A flag and prefix from its outgoing RAs. I do not agree with their interpretation of the standard (that in the presence of M flag, clients must not do SLAAC). -- Mikael Abrahamsson email: swmike@swm.pp.se From alexandru.petrescu@gmail.com Wed Aug 1 09:24:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957D411E8186 for ; Wed, 1 Aug 2012 09:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpDIuCKr-sSi for ; Wed, 1 Aug 2012 09:24:19 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 941A811E8183 for ; Wed, 1 Aug 2012 09:24:19 -0700 (PDT) Received: by ghbg16 with SMTP id g16so8061199ghb.31 for ; Wed, 01 Aug 2012 09:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8OUNwsZzomyS/UpvAWbREN/gxdPIFn07yTxWpAMEJ2A=; b=BY+m32RMpM5R4Dt/b3CbzLeNgb6TfRfd+LS+i0vBSW6zCPa9ZpGr4A8UeI/iEkFBFS KZLeH7U6hdsoXazjSm0lxUh8pblMsaeW222gZ/ychBbmhfIA+URuqRikfMiDo7tYzvR/ /oVMiN9CoCQwtddeg8oRvLa0CHzAG3G4R1qxk9+uqJ7g/Y1ET9plSEegXnNV9s7vbT0W D9m4w6HlZA92sfwb8TevL5b0JPNiaB+WHiASy1l6WnEnWhY1jCLZDDHHVPaGHRe4amDJ 4Djl9umFL2oCm37PPN07u830mTYMhW5x3thJ69tLJlvv6DlEWwY433L1PYuq8PrBvVAl +1iQ== Received: by 10.66.75.201 with SMTP id e9mr40996416paw.54.1343838258900; Wed, 01 Aug 2012 09:24:18 -0700 (PDT) Received: from [130.129.19.61] (dhcp-133d.meeting.ietf.org. [130.129.19.61]) by mx.google.com with ESMTPS id qd10sm2869956pbb.38.2012.08.01.09.24.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 09:24:18 -0700 (PDT) Message-ID: <50195829.5090609@gmail.com> Date: Wed, 01 Aug 2012 09:24:09 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ipv Subject: RS reliability vs frequent RAs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:24:20 -0000 In the past the frequency of sending RAs has been improved reducing interval down to milliseconds, with the goal of getting connectivity faster, in mobility scenarios. Would this be enough for these cases? Alex From Francis.Dupont@fdupont.fr Wed Aug 1 09:36:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48B321F888A for ; Wed, 1 Aug 2012 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcH8Yz5gbsdB for ; Wed, 1 Aug 2012 09:36:53 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E793B21F88FF for ; Wed, 1 Aug 2012 09:36:52 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q71Gae01078041; Wed, 1 Aug 2012 18:36:40 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201208011636.q71Gae01078041@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: RS reliability vs frequent RAs In-reply-to: Your message of Wed, 01 Aug 2012 09:24:09 PDT. <50195829.5090609@gmail.com> Date: Wed, 01 Aug 2012 18:36:40 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Ipv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:36:55 -0000 In your previous mail you wrote: > In the past the frequency of sending RAs has been improved reducing > interval down to milliseconds, with the goal of getting connectivity > faster, in mobility scenarios. => do you mean to misuse RAs as a beacon (:-)? Seriously the issue is pretty similar to the DHCP one so I believe Suresh's proposal is the right thing to do (and the room too according to hum's). Regards Francis.Dupont@fdupont.fr From achatz@forthnetgroup.gr Wed Aug 1 09:42:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915D11E816E for ; Wed, 1 Aug 2012 09:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viH1JHui5y2u for ; Wed, 1 Aug 2012 09:42:57 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8976511E8186 for ; Wed, 1 Aug 2012 09:42:51 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q71GgnIp010689 for ; Wed, 1 Aug 2012 19:42:49 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q71GgnTo019963 for ; Wed, 1 Aug 2012 19:42:49 +0300 Received: from [130.129.20.221] (dhcp-14dd.meeting.ietf.org [130.129.20.221]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q71GgXLd001009; Wed, 1 Aug 2012 19:42:35 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50195C84.2000206@forthnetgroup.gr> Date: Wed, 01 Aug 2012 09:42:44 -0700 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: draft-ietf-6man-uri-zoneid-02 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:42:58 -0000 Wouldn't it be an option to have all applications & systems accept as input both formats, but only give as output the new one? i.e. browsers already rewrite URIs. -- Tassos From dthaler@microsoft.com Wed Aug 1 10:12:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE48611E8210 for ; Wed, 1 Aug 2012 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.692 X-Spam-Level: X-Spam-Status: No, score=-103.692 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc6peawwshhI for ; Wed, 1 Aug 2012 10:12:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 44C4811E821B for ; Wed, 1 Aug 2012 10:12:22 -0700 (PDT) Received: from mail184-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 17:12:21 +0000 Received: from mail184-ch1 (localhost [127.0.0.1]) by mail184-ch1-R.bigfish.com (Postfix) with ESMTP id 23FC8800DC; Wed, 1 Aug 2012 17:12:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzc85fh1b0bIzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail184-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail184-ch1 (localhost.localdomain [127.0.0.1]) by mail184-ch1 (MessageSwitch) id 1343841139728996_28198; Wed, 1 Aug 2012 17:12:19 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail184-ch1.bigfish.com (Postfix) with ESMTP id A2D001E00C8; Wed, 1 Aug 2012 17:12:19 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 17:12:17 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 1 Aug 2012 17:12:10 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Wed, 1 Aug 2012 10:12:10 -0700 From: Dave Thaler To: "ipv6@ietf.org" Subject: Luis Santos's question on rfc3484bis Thread-Topic: Luis Santos's question on rfc3484bis Thread-Index: Ac1wBz1Qw6StQnPtSVGlo2mvv8PA0g== Date: Wed, 1 Aug 2012 17:12:09 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B732EA3@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B732EA3TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "lsantos@isec.pt" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:12:23 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B732EA3TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I mentioned this at the mic during the meeting and now posting the same to the list... Luis Santos asked a question to the authors which I'll explain to the list as follows. RFC 3484, and RFC 3484 bis, specify an algorithm whereby a set of destination addresses are sorted, and a source address for each is chosen. So if there's only one destination address, there's just one entry returned and if you have two source addresses, the list will only have one possibility. A more complicated algorithm would return a list of sorted pairs, where the dest addr could occur in multiple pairs. Based on the fact the doc is in the RFC editors queue, I don't think it's appropriate to add another algorithm into the same document, and so we leave this out of scope of the current document. That's what we said at the beginning of the 6man meeting today. And FYI as a data point, Windows does expose both types of algorithms (the 3484 type, and the sorted-pairs type) to applications. A sorted pairs algorithm is exposed via APIs such as CreateSortedAddressPairs() and DatagramSocket.GetEndpointPairsAsync(). -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B732EA3TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I mentioned this at the mic during the meeting and n= ow posting the

same to the list…

 

Luis Santos asked a question to the authors which I&= #8217;ll explain to the list

as follows.   RFC 3484, and RFC 3484 bis, = specify an algorithm whereby

a set of destination addresses are sorted, and a sou= rce address for each

is chosen.   So if there’s only one = destination address, there’s just one

entry returned and if you have two source addresses,= the list will only

have one possibility.  A more complicated algor= ithm would return a list

of sorted pairs, where the dest addr could occur in = multiple pairs.

 

Based on the fact the doc is in the RFC editors queu= e, I don’t think

it’s appropriate to add another algorithm into= the same document,

and so we leave this out of scope of the current doc= ument.   That’s

what we said at the beginning of the 6man meeting to= day.

 

And FYI as a data point, Windows does expose both ty= pes of algorithms

(the 3484 type, and the sorted-pairs type) to applic= ations.  A

sorted pairs algorithm is exposed via APIs such as <= o:p>

CreateSortedAddressPairs() and DatagramSocket.GetEnd= pointPairsAsync().

 

-Dave

 

--_000_9B57C850BB53634CACEC56EF4853FF653B732EA3TK5EX14MBXW604w_-- From j.schoenwaelder@jacobs-university.de Wed Aug 1 10:16:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A711E826D for ; Wed, 1 Aug 2012 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S26neV7LnMsC for ; Wed, 1 Aug 2012 10:16:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 31ADE11E8266 for ; Wed, 1 Aug 2012 10:16:36 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A61C20BFD; Wed, 1 Aug 2012 19:16:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id s42wBNwGdUF2; Wed, 1 Aug 2012 19:16:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C4D520BFE; Wed, 1 Aug 2012 19:16:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3199020FF8A9; Wed, 1 Aug 2012 19:16:34 +0200 (CEST) Date: Wed, 1 Aug 2012 19:16:33 +0200 From: Juergen Schoenwaelder To: Tassos Chatzithomaoglou Subject: Re: draft-ietf-6man-uri-zoneid-02 Message-ID: <20120801171633.GA83947@elstar.local> Mail-Followup-To: Tassos Chatzithomaoglou , ipv6@ietf.org References: <50195C84.2000206@forthnetgroup.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50195C84.2000206@forthnetgroup.gr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:16:36 -0000 On Wed, Aug 01, 2012 at 09:42:44AM -0700, Tassos Chatzithomaoglou wrote: > Wouldn't it be an option to have all applications & systems accept > as input both formats, but only give as output the new one? > i.e. browsers already rewrite URIs. There are other standards that currently state that % is the canonical format for zone identifier separation. We would have to revise those standards (and all standards using those standards) and for some of them this is not just a simple update due to the way versioning works. As such, a new '-' notation won't be accepted by certain interfaces for a long time. In other words, we cause problems (perhaps for 10-20 years) where there are currently no problems. And the question is whether this price is justified to address the zone identifier in URI issue. For me, the priority is this: a) Check seriously whether %en1 is really not acceptable since there really is no ambiguity. Using this notation is what the user wants. b) If a) is indeed not possible, simply apply the URI escaping rules, that is %25en1. This is consistent with URI escaping (which might happen on other parts of the zone index as well). Provide advise that URI parser implementors may accept %en1 (when it is unambiguous) and turn it into %25en1. (Many browsers already do this kind of thing today for other characters that need escaping.) I see no value in introducing a new separator. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tsavo.stds@gmail.com Wed Aug 1 10:36:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E919B21F88D6 for ; Wed, 1 Aug 2012 10:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxaPvj8CnbEM for ; Wed, 1 Aug 2012 10:36:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2439921F88CE for ; Wed, 1 Aug 2012 10:36:12 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so1446366pbb.31 for ; Wed, 01 Aug 2012 10:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Qv27hfyBV4OiiK/CdYq9yJ4A4/hzI7u5k/9nTIYbwe4=; b=cTXcZF/DHX9/PR+cF3b8r99YGXqH3rkCoGh13Nia6y4UFV5kOw+1aCgSZmN87gi4HP 4KiJhlPzR4I7rNeLAJWZTMm2/kMSuI0kKU3HcARS19RygRpFaWCYcVrVGZTZHvT3F5li g6uCFAiDLRO/eeDwUBqGVp31dDtj1DuhOYYDpsYwJyGJlljR56Tx8yNjsyxrjbj9EQx2 JO3hPPmkVRewjdGx5e5vlVp3E/guz4ZfCtRRykbaRzf8+zMMfmMqyx4MdmUh2Wa+HUX+ 3eAEQ4bDYp2mzqiGncU3YunUEnPGqpnCuM2SZldAEFHW0N1rUMEV/ScefNlDzIJYuzOp 39IQ== MIME-Version: 1.0 Received: by 10.68.130.233 with SMTP id oh9mr18700178pbb.78.1343842571702; Wed, 01 Aug 2012 10:36:11 -0700 (PDT) Received: by 10.68.220.230 with HTTP; Wed, 1 Aug 2012 10:36:11 -0700 (PDT) Date: Wed, 1 Aug 2012 10:36:11 -0700 Message-ID: Subject: Additional measurement information about draft-savolainen-6man-optimal-transmission-window From: Teemu Savolainen To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=047d7b10c8651ed35d04c637bbbd X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:36:13 -0000 --047d7b10c8651ed35d04c637bbbd Content-Type: text/plain; charset=ISO-8859-1 Hi, I just promised to send some additional information about the power consumption graphs I was just showing. The "idle" current draw (WiFi tethering on, phone on, cellular idle) in one of the measurement was about 138mA (in the figures I had this was the zero-line). When the cellular interface got active the current draw increased to about 323mA (i.e. in this measurement the cellular interface draws about 185mA, or accounts for 57% of handset's current total draw when active). In the three shown artificial scenarios (40s periodic messages) the average current drawn by gateway's cellular interface were: 1) 20s difference in packets: 87mA 2) 5s difference in packets: 64mA 3) 1s difference in packets: 37mA Obviously the achieved power savings range from virtually none to very significant, fully depending on the frequency of periodic messages nodes in a scenario are emitting and what is the power consumed by local area network interface. If the local area network would be low-power network (802.15.4, BT-LE), the relative power consumed by cellular interface would be significantly higher than in the case of this measurement where local network was WLAN. Best regards, Teemu --047d7b10c8651ed35d04c637bbbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I just promised to send some additional information about the po= wer consumption graphs I was just showing.

The "idle" curr= ent draw (WiFi tethering on, phone on, cellular idle) in one of the measure= ment was about 138mA (in the figures I had this was the zero-line).

When the cellular interface got active the current draw increased to ab= out 323mA (i.e. in this measurement the cellular interface draws about 185m= A, or accounts for 57% of handset's current total draw when active).
In the three shown artificial scenarios (40s periodic messages) the ave= rage current drawn by gateway's cellular interface were:

1) 20s = difference in packets: 87mA

2) 5s difference in packets: 64mA

3) 1s difference in packets: 37mA

Obviously the achieved power s= avings range from virtually none to very significant, fully depending on th= e frequency of periodic messages nodes in a scenario are emitting and what = is the power consumed by local area network interface. If the local area ne= twork would be low-power network (802.15.4, BT-LE), the relative power cons= umed by cellular interface would be significantly higher than in the case o= f this measurement where local network was WLAN.

Best regards,

Teemu
--047d7b10c8651ed35d04c637bbbd-- From achatz@forthnetgroup.gr Wed Aug 1 11:06:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0511E80FD for ; Wed, 1 Aug 2012 11:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1PWTSU5ZHP2 for ; Wed, 1 Aug 2012 11:06:39 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id EE9A311E83CE for ; Wed, 1 Aug 2012 11:06:38 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id q71I6bWi003331 for ; Wed, 1 Aug 2012 21:06:37 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q71I6bLI001840 for ; Wed, 1 Aug 2012 21:06:37 +0300 Received: from [130.129.20.221] (dhcp-14dd.meeting.ietf.org [130.129.20.221]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q71I6Xgc009116; Wed, 1 Aug 2012 21:06:36 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50197034.2020407@forthnetgroup.gr> Date: Wed, 01 Aug 2012 11:06:44 -0700 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: draft-gont-6man-predictable-fragment-id Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:06:40 -0000 I personally like the idea of making it a standard, just to have it as a reference for future IPv6 implementations. imho, security related issues should preferably be solved by changing the protocol, unless it's too much work; strict recommendations should then be given. We had a hard time in the past persuading vendors to implement informational RFCs. I also agree that a separate document should be written in order to give guidance to future protocol implementations. -- Tassos From leo.liubing@huawei.com Wed Aug 1 13:37:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0260911E81B6; Wed, 1 Aug 2012 13:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI7qyCgjQVv4; Wed, 1 Aug 2012 13:37:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F62511E819B; Wed, 1 Aug 2012 13:37:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP49853; Wed, 01 Aug 2012 12:37:23 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 13:35:57 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 13:35:55 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 04:35:49 +0800 From: "Liubing (Leo)" To: Karl Auer , IETF IPv6 , "renum@ietf.org" Subject: RE: about DHCPv6/SLAAC interaction Thread-Topic: about DHCPv6/SLAAC interaction Thread-Index: Ac1vfdpTtZ0CYGh1QuaTQPkL4ATaQwADX/+AACQkRMs= Date: Wed, 1 Aug 2012 20:35:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs>, <1343816057.26898.384.camel@karl> In-Reply-To: <1343816057.26898.384.camel@karl> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:37:25 -0000 Hi, all Firstly, thanks for Karl's elaborate analysis and solution proposal for the= M/O issue. I think that's definitely reasonable reference if we want to fi= x the issue. But as some comments showed in this morning's 6man meeting, some people tho= ught it is not necessary to fix the M/O issue in standard, because it used = to be long discussions about it, and current SLAAC standard (RFC4862) was j= ust based on the discussion result at that time. May I venture to argue that, "had been discussed before" might not be reaso= nable enough to deal with current problems. I think the situation has chang= ed since the RFC4862 published, more and more real IPv6 deployments are eme= rging, then people find it is quite confusing of the ambiguous M/O definiti= on, this real-network problem may be much more sensitive than we imagined/d= iscussed to be when writing RFC4862. We have two address autoconfiguration modes (SLAAC/DHCPv6) in IPv6, which = is one of the most significant differences between IPv4, people who have re= ally deployed IPv6 may notice more importance of SLAAC/DHCPv6 interaction t= han we discussed before, at least I've learned the requirements from both o= ffline and on the mics, maybe it is not comprehensive enough, but at least = it's considerable. So, my personal preference is similar with Karl's, we might need additional= flags to cover the SLAAC/DHCPv6 interaction semantics. And in 6renum, we a= lso discussed some new semantics requirements (see in the draft, and the se= ction 5.1 in 6renum WG item: http://tools.ietf.org/html/draft-ietf-6renum-g= ap-analysis-02 ), I think they are also considerable. Regards, Bing ________________________________________ From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] on behalf of Karl Auer = [kauer@biplane.com.au] Sent: Wednesday, August 01, 2012 03:14 To: IETF IPv6 Subject: Re: about DHCPv6/SLAAC interaction On Wed, 2012-08-01 at 01:06 +0000, Liubing (Leo) wrote: > You mentioned the ambiguous M flag in RA, indeed this is a problem, > and it has been disscussed in 6renum WG. > > So if you're still consern about the issue, looking forward to hear > some comments from you, either on the mics or in the mail. [Leo sent me the above off list, but I post my reply here with his permission] Thanks! A host should always be allowed to do DHCPv6 in the *absence* of information to the contrary; this is no different to NOT doing DHCPv6 in the absence of information. Also, a host may be in a self-contained or isolated network, i.e., one without a router, but with a DHCP server. So NOT receiving RAs is no reason NOT to do DHCPv6. Nor is it a reason to do it either, of course - i.e., it's up to the host :-) I'll preface all this my saying that I think the M and O flags as generally implemented and used are pretty much useless. The best thing to do with them would be to deprecate them altogether. If they must be retained, then I feel that the semantics should be as follows, and as far as I can tell from the RFC, this is all allowed: ......= From kauer@biplane.com.au Wed Aug 1 17:08:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F212F11E809B; Wed, 1 Aug 2012 17:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fnRv-gFGedW; Wed, 1 Aug 2012 17:08:57 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC9111E80EC; Wed, 1 Aug 2012 17:08:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAL7EGVCWZX+7/2dsb2JhbAANOIV7tj4BAQEDASNbCwsYAgImAgJXBgEShhGBdhGpLG6TKoEhkB+BEgOWW4l5h3GBTQ Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Aug 2012 09:38:45 +0930 Subject: RE: about DHCPv6/SLAAC interaction From: Karl Auer To: IETF IPv6 , "renum@ietf.org" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> ,<1343816057.26898.384.camel@karl> <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Aug 2012 10:08:29 +1000 Message-ID: <1343866109.26898.507.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:08:58 -0000 On Wed, 2012-08-01 at 20:35 +0000, Liubing (Leo) wrote: > May I venture to argue that, "had been discussed before" might not be > reasonable enough to deal with current problems. What exactly are "the current problems"? It seems to me there are only two: - it is not explicit whether M means a host "must", "should" or "may" use DHCPv6 to obtain an address. It is fairly clear in practice that this is a "should" - it is not explicit that the M and O flags are completely independent of each other. Common practice is to treat them as independent, and I can see no good reason to link them in the RFC or anywhere else. - there is a question about whether a host obtaining a DHCPv6 address should NOT perform SLAAC. Since the RFC certainly doesn't say it should, it is a mystery to me why people think DHCPv6 excludes SLAAC. Access to addresses via DHCPv6 can be completely controlled on a subnet by subnet basis in the DHCP server, and SLAAC can be completely controlled on a subnet by subnet basis using the autoconf flag in RAs. - if I were King of the World I would deprecate both flags. They serve no useful purpose. > this real-network problem may be much more sensitive than we > imagined/discussed to be when writing RFC4862. Again, I don't see the issue(s) here. > So, my personal preference is similar with Karl's, we might need > additional flags to cover the SLAAC/DHCPv6 interaction semantics. That is NOT my preference. My preference is to deprecate both flags. My second preference is to clarify as above. All that stuff about additional flags was thinking aloud about how M/O could be made mandatory; it was certainly NOT a suggestion that they *should* be made mandatory. > And in 6renum, we also discussed some new semantics requirements (see > in the draft, and the section 5.1 in 6renum WG item: > http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-02 ), I've just read that doc and as far as DHCP and SLAAC go, it seems to be composed mostly of questions. I really think the draft should state what the *problems* are that it seeks to solve. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From alexandru.petrescu@gmail.com Wed Aug 1 17:58:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93E021F897B for ; Wed, 1 Aug 2012 17:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.731 X-Spam-Level: X-Spam-Status: No, score=-3.731 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8bK9EDkAMa5 for ; Wed, 1 Aug 2012 17:58:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35FD421F8979 for ; Wed, 1 Aug 2012 17:58:33 -0700 (PDT) Received: by yhq56 with SMTP id 56so8654927yhq.31 for ; Wed, 01 Aug 2012 17:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=E5dRxOcDQikojGcGDq6el8FY07jjOHvxHog8C/Ip4Eo=; b=csfmIOA2aIITj8TruXa2Z6lxN3ipfXd8NGP7E89urUA5tk2KduZIPuczLEGCoO3gZE Mu68ejvZejoLpE2emUF7WdCNOMiEb3mvXmqdUpUPIG0hTf4T4r1J/295C1QzfkXde0LY 6rUY0CqK7QnmjPBQsM4RYPCynYCwMLa50N78oTSt+k7y80clwrXnaeL/TRi+oZ41RhoF woSuB0bN6lvu1PZRd8TUvNrDkLvKdyR/xsFilgwVbcxOWSIiNYXukrOpobR/nvDyVxXm S1uWTyDjS2aW9aHLjXO3b+EtaHJol7yYjZ2qth1V6SnBCfg/P9fzcrqXhf1zDqdQ4u9k nyrA== Received: by 10.50.41.201 with SMTP id h9mr72961igl.37.1343869112623; Wed, 01 Aug 2012 17:58:32 -0700 (PDT) Received: from [130.129.54.43] (dhcp-362b.meeting.ietf.org. [130.129.54.43]) by mx.google.com with ESMTPS id k6sm14038704igz.9.2012.08.01.17.58.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 17:58:32 -0700 (PDT) Message-ID: <5019D0AE.3090803@gmail.com> Date: Wed, 01 Aug 2012 17:58:22 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: about DHCPv6/SLAAC interaction References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs>, <1343816057.26898.384.camel@karl> <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:58:34 -0000 Le 01/08/2012 13:35, Liubing (Leo) a écrit : > Hi, all > > Firstly, thanks for Karl's elaborate analysis and solution proposal > for the M/O issue. I think that's definitely reasonable reference if > we want to fix the issue. > > But as some comments showed in this morning's 6man meeting, some > people thought it is not necessary to fix the M/O issue in standard, > because it used to be long discussions about it, and current SLAAC > standard (RFC4862) was just based on the discussion result at that > time. May I venture to argue that, "had been discussed before" might > not be reasonable enough to deal with current problems. I think the > situation has changed since the RFC4862 published, more and more > real IPv6 deployments are emerging, then people find it is quite > confusing of the ambiguous M/O definition, this real-network problem > may be much more sensitive than we imagined/discussed to be when > writing RFC4862. > > We have two address autoconfiguration modes (SLAAC/DHCPv6) in IPv6, > which is one of the most significant differences between IPv4, > people who have really deployed IPv6 may notice more importance of > SLAAC/DHCPv6 interaction than we discussed before, at least I've > learned the requirements from both offline and on the mics, maybe it > is not comprehensive enough, but at least it's considerable. > > So, my personal preference is similar with Karl's, we might need > additional flags to cover the SLAAC/DHCPv6 interaction semantics. > And in 6renum, we also discussed some new semantics requirements (see > in the draft, and the section 5.1 in 6renum WG item: > http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-02 ), I > think they are also considerable. I will not oppose any initiative to improve the ambiguous situation of the M/O flags. The choice today is more than b/w 'if M then DHCP is available otherwise SLAAC'. Both DHCP and SLAAC advanced towards doing what the other does, and it is _still_ possible to need some features from one and some from the other - it's still impossible to use just one for everything. (eg RA doesnt PD, DHCP doesnt MTU, and more) A more complete M/O set of flags would be something like telling "use DHCP for PD and use SLAAC for default route" or so. But not sure whether this is the right thing to do either. Alex From kauer@biplane.com.au Wed Aug 1 18:48:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD6621F8949 for ; Wed, 1 Aug 2012 18:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1LbcddI-njh for ; Wed, 1 Aug 2012 18:48:23 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 407FB21F8943 for ; Wed, 1 Aug 2012 18:48:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAM7bGVCWZX+7/2dsb2JhbAANOIV7tkIBAQEDASNbCwsYAgImAgJXBhOIB6k9bpMygSGQH4ESA6BUh3E Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Aug 2012 11:18:20 +0930 Subject: Re: about DHCPv6/SLAAC interaction From: Karl Auer To: IETF IPv6 In-Reply-To: <5019D0AE.3090803@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> , <1343816057.26898.384.camel@karl> <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> <5019D0AE.3090803@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Aug 2012 11:48:17 +1000 Message-ID: <1343872097.26898.534.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:48:25 -0000 On Wed, 2012-08-01 at 17:58 -0700, Alexandru Petrescu wrote: > The choice today is more than b/w 'if M then DHCP is available > otherwise SLAAC'. That has never been the choice. It's never been either/or, one excluding the other. Rock solid mechanisms exist to stop hosts doing SLAAC - the autoconf flag, which DOES impose mandatory behaviour on the host, or, worst-case, use of a non/64. And a rock solid method exists to stop hosts doing DHCPv6 - just don't provide service to the subnet. Neither mechanism is onerous, neither method is complex. > Both DHCP and SLAAC advanced towards doing what the other does, > and it is _still_ possible to need some features from one and some > from the other - it's still impossible to use just one for everything. > (eg RA doesnt PD, DHCP doesnt MTU, and more) You are talking here about what information is delivered via the two mechanisms, not the operations of the mechanisms themselves. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From alexandru.petrescu@gmail.com Wed Aug 1 19:02:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0567D11E817D for ; Wed, 1 Aug 2012 19:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoRfUXqSg48G for ; Wed, 1 Aug 2012 19:02:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5376711E8175 for ; Wed, 1 Aug 2012 19:02:16 -0700 (PDT) Received: by yhq56 with SMTP id 56so8713786yhq.31 for ; Wed, 01 Aug 2012 19:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=c/zkNHcld/AWjBpYNVS5dSYUTEVY4vbFdYAmcRHVF20=; b=uGOKWeQhzkZcmIqfm5YVObjv188bOYFKX7zMRONrwAgCoSjl3qxmUeLp5tooULz+q8 h4h2uip8HKQgwVt3p+u/nCbI5/5E5TIdUbxuVQCdtxMaTpwnmXe5mHV7UbigjEIH//4f T9ArMhm9XzpBQnpWH4eH0nX9tplTw5AhPsq0UIsOMFd6Adz2XQ0f6BbKBjjnU/4uhtiy ujW5W69FjRSVh50kQrg/wM/NQLcd1tx08fKlwKHrqRdGUGlg4t6cfQHXz5ae6AOswb3/ IPo6f7MXXZHIBKzKjwdJHuVwO77zZegeGVvtOY4VzUV0RbmiJhV9CbF+8Ps+e7915hME asJA== Received: by 10.50.217.163 with SMTP id oz3mr473370igc.5.1343872935783; Wed, 01 Aug 2012 19:02:15 -0700 (PDT) Received: from [130.129.54.43] (dhcp-362b.meeting.ietf.org. [130.129.54.43]) by mx.google.com with ESMTPS id gh2sm9249894igb.9.2012.08.01.19.02.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 19:02:15 -0700 (PDT) Message-ID: <5019DF9D.5050300@gmail.com> Date: Wed, 01 Aug 2012 19:02:05 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: about DHCPv6/SLAAC interaction References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> , <1343816057.26898.384.camel@karl> <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> <5019D0AE.3090803@gmail.com> <1343872097.26898.534.camel@karl> In-Reply-To: <1343872097.26898.534.camel@karl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:02:21 -0000 Le 01/08/2012 18:48, Karl Auer a écrit : > On Wed, 2012-08-01 at 17:58 -0700, Alexandru Petrescu wrote: >> The choice today is more than b/w 'if M then DHCP is available >> otherwise SLAAC'. > > That has never been the choice. It's never been either/or, one > excluding the other. Ok fair enough. The eisting M/O are like hints - suggestions. > Rock solid mechanisms exist to stop hosts doing SLAAC - the autoconf > flag, which DOES impose mandatory behaviour on the host, or, > worst-case, use of a non/64. And a rock solid method exists to stop > hosts doing DHCPv6 - just don't provide service to the subnet. Right... > Neither mechanism is onerous, neither method is complex. > >> Both DHCP and SLAAC advanced towards doing what the other does, >> and it is _still_ possible to need some features from one and some >> from the other - it's still impossible to use just one for >> everything. (eg RA doesnt PD, DHCP doesnt MTU, and more) > > You are talking here about what information is delivered via the two > mechanisms, not the operations of the mechanisms themselves. Right. Let me try to better explain. In a static environment, where the PC always wakes up on the same desk, this avialability of DHCP vs SLAAC is easily decided once for several months. This could happen easily with just M/O, or simply by the absence of DHCP Server. But in mobile environment, a mobile router moving aroung attaching to other mobile router needs to be able to face quickly various ways of delivering this configuration data. If one considers simply the triplet address-defroute-prefixdelegated then there are about 8 possibilities to deliver that to a Router, by using DHCP and ND combinations. Which of the 8 should the router try first? One neighboring vehicle would deliver it address-defroute-prefixdelegated by DHCP, another one by SLAAC and yet another one by a combination of the two. In order to test for the availability of which of DHCP/ND delivers which of address-defroute-prefixdelegated, one would send several RSs and several DHCP Requests. This may be too much for routers which constantly move. Ideally, such a Router would just send an RS, receive some capability, and subsequently executing DHCPReq depending whats in that RA. This would require more than just M/O flags. And yes I agree this would be more that what a wide agreement could be reached on M/O... Just some thought. Alex > > Regards, K. > From leo.liubing@huawei.com Wed Aug 1 21:27:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E0411E8122; Wed, 1 Aug 2012 21:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rfr3wqArewP; Wed, 1 Aug 2012 21:27:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E013711E8109; Wed, 1 Aug 2012 21:27:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII75950; Wed, 01 Aug 2012 20:27:36 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 21:24:03 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 21:24:07 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 12:23:11 +0800 From: "Liubing (Leo)" To: Karl Auer , IETF IPv6 , "renum@ietf.org" Subject: RE: about DHCPv6/SLAAC interaction Thread-Topic: about DHCPv6/SLAAC interaction Thread-Index: Ac1vfdpTtZ0CYGh1QuaTQPkL4ATaQwADX/+AACQkRMv//8fwgIAAr5Oc Date: Thu, 2 Aug 2012 04:23:09 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F452932BF44@szxeml509-mbs> References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> ,<1343816057.26898.384.camel@karl> <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs>, <1343866109.26898.507.camel@karl> In-Reply-To: <1343866109.26898.507.camel@karl> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Alexandru Petrescu \[alexandru.petrescu@gmail.com\]" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 04:27:38 -0000 Hi, Karl Thanks for your reply, now I understand your arguments clearly.=20 I think our common view is "ambiguity in not good". Then your way is just d= eprecating them; if don't deprecate, then make it clear. But I just have th= e opposite approach: since it's ambiguous, we need at least make them clear= , and beyond, we need more SLAAC/DHCPv6 interaction than the original M/O f= lags semantics. Let me explain what are "the current problems": [1]. Renumbering problems.=20 In RFC5887(Renumbering still needs work), section 5.1.1 says clearly: =20 "Until this ambiguous behaviour is clearly resolved by the IETF, operational problems are to be expected, since different host operating systems have taken different approaches. This makes it difficult for a site network manager to configure systems in such a way that all hosts boot in a consistent way. Hosts will start SLAAC, if so directed by appropriately configured RA messages. However, if one operating system also starts a DHCPv6 client by default, and another one starts it only when it receives the M bit, systematic address management is impeded." Our test had identified the host OSes have tanken different apporoaches. Fo= r the above mentioned "systematic address management" , we already discusse= d several instance, as I described in the draft: - The site manager wants the host to do DHCPv6 when online. Current pra= ctise is sending RA M=3D1 and don't include PIO, however, how the OSes will= behave is not controlled by the site. - The site manager wants the SLAAC-configured hosts to do DHCPv6 (e.g. = adding a multihomed uplink who uses DHCPv6 for address configuration). For= some OSes, there's just no availeble method. - The site manager wants the DHCPv6-configured hosts switch to SLAAC. I= f you don't interprete M=3D0 as prescriptive, the only way is either just w= aiting for the DHCPv6 lease time expires, or initial DHCPv6-reocnfiguration= from the server side. But I don't think it is an efficient way when renu= mbering. If the lease time is too long, the problem is more serious. For D= HCPv6-reocnfiguration, it is only unicast, and stateful, not proper for bul= k use.=20 [2] Requirement from ISP ISPs have strong requirement of strictly controlling the CPE behaving as th= ey expect. There's an instance I learned, an ISP deployed stateless DHCPv6 = in their IPv6 network, which means they required the CPE to=20 configure addresses through SLAAC and other parameters through DHCPv6. Sinc= e the ambiguity in standard, they had to directly specify the requirements = to the CPE vendor, which means, universal CPE may not be availeble in IPv6 = networks unless we have clear definition in standard. [3] I think Alexandru's argument of mobile nodes is another good example. Regards, Bing ________________________________________ From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] on behalf of Karl Auer = [kauer@biplane.com.au] Sent: Wednesday, August 01, 2012 17:08 To: IETF IPv6; renum@ietf.org Subject: RE: about DHCPv6/SLAAC interaction On Wed, 2012-08-01 at 20:35 +0000, Liubing (Leo) wrote: > May I venture to argue that, "had been discussed before" might not be > reasonable enough to deal with current problems. What exactly are "the current problems"? It seems to me there are only two: - it is not explicit whether M means a host "must", "should" or "may" use DHCPv6 to obtain an address. It is fairly clear in practice that this is a "should" - it is not explicit that the M and O flags are completely independent of each other. Common practice is to treat them as independent, and I can see no good reason to link them in the RFC or anywhere else. - there is a question about whether a host obtaining a DHCPv6 address should NOT perform SLAAC. Since the RFC certainly doesn't say it should, it is a mystery to me why people think DHCPv6 excludes SLAAC. Access to addresses via DHCPv6 can be completely controlled on a subnet by subnet basis in the DHCP server, and SLAAC can be completely controlled on a subnet by subnet basis using the autoconf flag in RAs. - if I were King of the World I would deprecate both flags. They serve no useful purpose. > this real-network problem may be much more sensitive than we > imagined/discussed to be when writing RFC4862. Again, I don't see the issue(s) here. > So, my personal preference is similar with Karl's, we might need > additional flags to cover the SLAAC/DHCPv6 interaction semantics. That is NOT my preference. My preference is to deprecate both flags. My second preference is to clarify as above. All that stuff about additional flags was thinking aloud about how M/O could be made mandatory; it was certainly NOT a suggestion that they *should* be made mandatory. > And in 6renum, we also discussed some new semantics requirements (see > in the draft, and the section 5.1 in 6renum WG item: > http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-02 ), I've just read that doc and as far as DHCP and SLAAC go, it seems to be composed mostly of questions. I really think the draft should state what the *problems* are that it seeks to solve. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------= From dougb@dougbarton.us Wed Aug 1 21:40:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0054E21F87E8 for ; Wed, 1 Aug 2012 21:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfpAM7XyFXfW for ; Wed, 1 Aug 2012 21:40:04 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F42B21F87E7 for ; Wed, 1 Aug 2012 21:40:03 -0700 (PDT) Received: (qmail 22039 invoked by uid 399); 2 Aug 2012 04:39:56 -0000 Received: from unknown (HELO ?172.17.127.241?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 2 Aug 2012 04:39:56 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <501A04A0.6000100@dougbarton.us> Date: Wed, 01 Aug 2012 21:40:00 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: about DHCPv6/SLAAC interaction References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs>, <1343816057.26898.384.camel@karl> <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> <5019D0AE.3090803@gmail.com> In-Reply-To: <5019D0AE.3090803@gmail.com> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 04:40:06 -0000 On 8/1/2012 5:58 PM, Alexandru Petrescu wrote: > Le 01/08/2012 13:35, Liubing (Leo) a écrit : >> Hi, all >> >> Firstly, thanks for Karl's elaborate analysis and solution proposal >> for the M/O issue. I think that's definitely reasonable reference if >> we want to fix the issue. >> >> But as some comments showed in this morning's 6man meeting, some >> people thought it is not necessary to fix the M/O issue in standard, >> because it used to be long discussions about it, and current SLAAC >> standard (RFC4862) was just based on the discussion result at that >> time. May I venture to argue that, "had been discussed before" might >> not be reasonable enough to deal with current problems. I think the >> situation has changed since the RFC4862 published, more and more >> real IPv6 deployments are emerging, then people find it is quite >> confusing of the ambiguous M/O definition, this real-network problem >> may be much more sensitive than we imagined/discussed to be when >> writing RFC4862. >> >> We have two address autoconfiguration modes (SLAAC/DHCPv6) in IPv6, >> which is one of the most significant differences between IPv4, >> people who have really deployed IPv6 may notice more importance of >> SLAAC/DHCPv6 interaction than we discussed before, at least I've >> learned the requirements from both offline and on the mics, maybe it >> is not comprehensive enough, but at least it's considerable. >> >> So, my personal preference is similar with Karl's, we might need >> additional flags to cover the SLAAC/DHCPv6 interaction semantics. >> And in 6renum, we also discussed some new semantics requirements (see >> in the draft, and the section 5.1 in 6renum WG item: >> http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-02 ), I >> think they are also considerable. > > I will not oppose any initiative to improve the ambiguous situation of > the M/O flags. > > The choice today is more than b/w 'if M then DHCP is available otherwise > SLAAC'. Both DHCP and SLAAC advanced towards doing what the other does, > and it is _still_ possible to need some features from one and some from > the other - it's still impossible to use just one for everything. (eg > RA doesnt PD, DHCP doesnt MTU, and more) I've been following this discussion with interest because to be honest I've never understood the subtleties of the M/O bits. But I think that Alexandru just hit on the real problem here. We need to fix DHCPv6 so that it can be a complete solution first (and of course, keep the feature freeze on SLAAC/RA in place). Then the whole M/O thing gets much, much simpler. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From tore.anderson@redpill-linpro.com Thu Aug 2 01:20:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2021F8C40; Thu, 2 Aug 2012 01:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7lLIvI60Ant; Thu, 2 Aug 2012 01:20:46 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id DDF7C21F8C44; Thu, 2 Aug 2012 01:20:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id B20681820018; Thu, 2 Aug 2012 10:20:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJqE+yHI5Frw; Thu, 2 Aug 2012 10:20:42 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 2727D1820004; Thu, 2 Aug 2012 10:20:42 +0200 (CEST) Message-ID: <501A3859.6080300@redpill-linpro.com> Date: Thu, 02 Aug 2012 10:20:41 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Karl Auer Subject: Re: about DHCPv6/SLAAC interaction References: <8AE0F17B87264D4CAC7DE0AA6C406F452932B863@szxeml509-mbs> , <1343816057.26898.384.camel@karl> <8AE0F17B87264D4CAC7DE0AA6C406F452932BC36@szxeml509-mbs> <1343866109.26898.507.camel@karl> In-Reply-To: <1343866109.26898.507.camel@karl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IETF IPv6 , "renum@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 08:20:49 -0000 * Karl Auer > - it is not explicit that the M and O flags are completely > independent of each other. Common practice is to treat them as > independent, and I can see no good reason to link them in the RFC or > anywhere else. RFC 4861 section 4.2 seems to me to be pretty clear about this: «If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.» So the operational value of O is (M OR O), as I understand it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From brian.e.carpenter@gmail.com Thu Aug 2 03:10:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A60A21F8C6C for ; Thu, 2 Aug 2012 03:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOI96c+u53Jy for ; Thu, 2 Aug 2012 03:10:37 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B743021F8A83 for ; Thu, 2 Aug 2012 03:10:36 -0700 (PDT) Received: by eaai11 with SMTP id i11so90207eaa.31 for ; Thu, 02 Aug 2012 03:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/ph1+owMSs1rAecyTlhbhJNUfXims6oXdI6iGHcztA0=; b=x+7E8X+xvNvrkbgbVGOK06uwkEmD3HdLGlV8Z4oEVIxEWetrlsmMmcFnxvcu4XSA/p 8xy7h4Gj9rLRShzep1pbjV7xEjQzwqkKr9sPO1n8AGGEQ6cUcXXOQfBLJ8/Kj1JGaI/n MqTmil5/ilni8I4GlbbR/F2vESzt5dDpsirvshCMT88Om/7bMBLUZkODOtni+zQEDZ2Z w3wWJkfhkLMCOHuqRC7A9Y8jvsm8fAISCeHpFhpsGufRkfTuaBkV0ki41r9Og4YBcHiv yiT0ZUwsuqUIlhQmIWCSL75DD46EqzljCq9Y4vT2GwC4AQ8edn600xOTc+XNtzNVTVhm TpEg== Received: by 10.14.219.198 with SMTP id m46mr25953219eep.18.1343902233350; Thu, 02 Aug 2012 03:10:33 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-46.as13285.net. [2.102.219.46]) by mx.google.com with ESMTPS id s8sm16041440eeo.8.2012.08.02.03.10.31 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 03:10:32 -0700 (PDT) Message-ID: <501A5220.8040409@gmail.com> Date: Thu, 02 Aug 2012 11:10:40 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tassos Chatzithomaoglou , ipv6@ietf.org Subject: Re: draft-ietf-6man-uri-zoneid-02 References: <50195C84.2000206@forthnetgroup.gr> <20120801171633.GA83947@elstar.local> In-Reply-To: <20120801171633.GA83947@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 10:10:39 -0000 On 01/08/2012 18:16, Juergen Schoenwaelder wrote: > On Wed, Aug 01, 2012 at 09:42:44AM -0700, Tassos Chatzithomaoglou wrote: >> Wouldn't it be an option to have all applications & systems accept >> as input both formats, but only give as output the new one? >> i.e. browsers already rewrite URIs. > > There are other standards that currently state that % is the canonical > format for zone identifier separation. We would have to revise those > standards (and all standards using those standards) and for some of > them this is not just a simple update due to the way versioning works. > As such, a new '-' notation won't be accepted by certain interfaces > for a long time. In other words, we cause problems (perhaps for 10-20 > years) where there are currently no problems. And the question is > whether this price is justified to address the zone identifier in URI > issue. > > For me, the priority is this: > > a) Check seriously whether %en1 is really not acceptable since there > really is no ambiguity. Using this notation is what the user wants. Of course we have done that, twice (a few years ago and this year). Dead end. > > b) If a) is indeed not possible, simply apply the URI escaping rules, > that is %25en1. This is consistent with URI escaping (which might > happen on other parts of the zone index as well). Provide advise that > URI parser implementors may accept %en1 (when it is unambiguous) and > turn it into %25en1. (Many browsers already do this kind of thing > today for other characters that need escaping.) This, to my understanding, was already rejected by 6man some months ago, with the conclusion that a new separator is needed. It's not my job to make the consensus call, however. > > I see no value in introducing a new separator. The value is providing a long-term path to cut and paste. Otherwise, I assume we would indeed choose the %25 approach. Brian > > /js > From nordmark@acm.org Thu Aug 2 07:21:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0A21F85CE for ; Thu, 2 Aug 2012 07:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.235 X-Spam-Level: X-Spam-Status: No, score=-103.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3RPwmroNYh7 for ; Thu, 2 Aug 2012 07:21:21 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4755A21F85C7 for ; Thu, 2 Aug 2012 07:21:21 -0700 (PDT) Received: from [10.21.147.55] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q72ELH3e018119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 07:21:17 -0700 Message-ID: <501A8CDC.1000800@acm.org> Date: Thu, 02 Aug 2012 07:21:16 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: IETF IPv6 Subject: Fwd: New Version Notification for draft-ietf-6man-impatient-nud-02.txt References: <50186F50.8090106@acm.org> In-Reply-To: <50186F50.8090106@acm.org> X-Forwarded-Message-Id: <50186F50.8090106@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:21:21 -0000 -------- Original Message -------- Subject: New Version Notification for draft-ietf-6man-impatient-nud-02.txt Date: Tue, 31 Jul 2012 16:48:19 -0700 From: To: CC: A new version of I-D, draft-ietf-6man-impatient-nud-02.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-ietf-6man-impatient-nud Revision: 02 Title: Neighbor Unreachability Detection is too impatient Creation date: 2012-07-31 WG ID: 6man Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-impatient-nud-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud Htmlized: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-impatient-nud-02 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Thu Aug 2 09:29:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DEF21F860F for ; Thu, 2 Aug 2012 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu5TVaYftvIm for ; Thu, 2 Aug 2012 09:29:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4744121F860D for ; Thu, 2 Aug 2012 09:29:15 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B50420C07; Thu, 2 Aug 2012 18:29:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EtRUGQteZN3y; Thu, 2 Aug 2012 18:29:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B09F20BFF; Thu, 2 Aug 2012 18:29:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CAA2B2101DE4; Thu, 2 Aug 2012 18:29:13 +0200 (CEST) Date: Thu, 2 Aug 2012 18:29:13 +0200 From: Juergen Schoenwaelder To: Brian E Carpenter Subject: Re: draft-ietf-6man-uri-zoneid-02 Message-ID: <20120802162913.GA86509@elstar.local> Mail-Followup-To: Brian E Carpenter , Tassos Chatzithomaoglou , ipv6@ietf.org References: <50195C84.2000206@forthnetgroup.gr> <20120801171633.GA83947@elstar.local> <501A5220.8040409@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501A5220.8040409@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:29:16 -0000 On Thu, Aug 02, 2012 at 11:10:40AM +0100, Brian E Carpenter wrote: > > I see no value in introducing a new separator. > > The value is providing a long-term path to cut and paste. Otherwise, > I assume we would indeed choose the %25 approach. OK, I change my statement to: I do not believe that the value of introducing a new separator justifies its costs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kerlyn2001@gmail.com Thu Aug 2 10:57:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB211E818C for ; Thu, 2 Aug 2012 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE9zxGDIuzMh for ; Thu, 2 Aug 2012 10:57:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBC2011E816B for ; Thu, 2 Aug 2012 10:57:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1214462lbb.31 for ; Thu, 02 Aug 2012 10:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=iK9x9Af5Rkw4kINNEUVa1O+5etijh5wPKIxYxxcycDc=; b=zI4AopUVQMimoyiSQuLMwfUcr47P1Rii5wPDmPFkAVTBay9NPDUh7anJwF1+VF7xzr 7av6tnsIzjTIJjvwd/BMp0zsiA6Lbk6RrjKR55wrqse7LbNDf2aH7bDtiecyBk9pe6F4 nP1mVEbF2KctbDj70TXsIOeskRlQ2ahol00hMJcJNWN107BJqffDJIJ+k0YvvGjogNXe P2zTziAWf1kHXOnIBj9myNDKaavqHznsdfO8cukt2cMKtzZb2lxP3NQLsIFd4wOW9QNO d+y7LzfG9Gbvml8KgDXAS4B4aVmAXWJmjW2khkhC4Ldq7dJNZNgKpa+X8js3KIByoPcM 470Q== MIME-Version: 1.0 Received: by 10.112.10.198 with SMTP id k6mr10094933lbb.83.1343930247801; Thu, 02 Aug 2012 10:57:27 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.10.199 with HTTP; Thu, 2 Aug 2012 10:57:27 -0700 (PDT) In-Reply-To: <20120802162913.GA86509@elstar.local> References: <50195C84.2000206@forthnetgroup.gr> <20120801171633.GA83947@elstar.local> <501A5220.8040409@gmail.com> <20120802162913.GA86509@elstar.local> Date: Thu, 2 Aug 2012 13:57:27 -0400 X-Google-Sender-Auth: 5I8TiHEfti51qyx6x88UiHq5OJI Message-ID: Subject: Re: draft-ietf-6man-uri-zoneid-02 From: Kerry Lynn To: Juergen Schoenwaelder , Brian E Carpenter , Tassos Chatzithomaoglou , ipv6@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe350205ead704c64c25b5 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:57:30 -0000 --e0cb4efe350205ead704c64c25b5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 2, 2012 at 12:29 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 02, 2012 at 11:10:40AM +0100, Brian E Carpenter wrote: > > > > I see no value in introducing a new separator. > > > > The value is providing a long-term path to cut and paste. Otherwise, > > I assume we would indeed choose the %25 approach. > > OK, I change my statement to: > > I do not believe that the value of introducing a new separator > justifies its costs. > > Is there any value in trying to add "%%" to the URI BNF? This would seem to give us *almost* cut and paste (which we don't quite have now anyway, since we must add '[' and ']') while disambiguating whether "%251" means "%1" or "%251" to the browser UI ("%%1" -> "%251"). Lots of systems use ESC ESC to really mean ESC. -K- > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --e0cb4efe350205ead704c64c25b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 2, 2012 at 12:29 PM, Juergen Schoenwaelder &l= t;j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 02, 2012 at 11= :10:40AM +0100, Brian E Carpenter wrote:

> > I see no value in introducing a new separator.
>
> The value is providing a long-term path to cut and paste. Otherwise, > I assume we would indeed choose the %25 approach.

OK, I change my statement to:

=A0 I do not believe that the value of introducing a new separator
=A0 justifies its costs.

Is there any value in = trying to add "%%" to the URI BNF? =A0This would
seem t= o give us *almost* cut and paste (which we don't quite have now
anyway, since we must add '[' and ']') while disambiguating= whether
"%251" means "%1" or "%251"= ; to the browser UI ("%%1" -> "%251").

Lots of systems use ESC ESC to really mean ESC.
-K-

=A0
/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>
-----------------------------= ---------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--e0cb4efe350205ead704c64c25b5-- From alexandru.petrescu@gmail.com Thu Aug 2 09:35:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF321F8442 for ; Thu, 2 Aug 2012 09:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.673 X-Spam-Level: X-Spam-Status: No, score=-3.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ-a80Y-VKuk for ; Thu, 2 Aug 2012 09:35:01 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EBAE611E808E for <6man@ietf.org>; Thu, 2 Aug 2012 09:34:54 -0700 (PDT) Received: by qaea16 with SMTP id a16so1361922qae.10 for <6man@ietf.org>; Thu, 02 Aug 2012 09:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ahh3rA+z7x14MRxrvznAVRNrzqPKd6IVboouFyLD1ng=; b=uYMyd+Evu/ONyd8c/NjnKFBCowlBv8jpWv7j9jCzaEfdKNqWzLGtTDZ3HGbMvppe85 0QWXZqzHHOcqtxSmVBIzPWeonlS+V+7FOVrH8S/LeOIR7d1Qi2PuGSlq+lLG9X07zZGH LbmC8Y5Z0ePylW3bwo1sF0i/G2SoijSY6Y+uvo/2xHhIb7EcrkBji4gcp5E0DmQBaoOP ihwLhPv1ERS4GPxL6jQYTEaz3JaG3ZgNdAmYv/c3Bsm8PUJ4PuZVRIoiCug3p8QRrpb0 auanNAZWjFIaKyILnwUJU1QiMhcmYTCpugM2XwMwhyqF+WdDUyebs2G88NxFuJoZ0Iuk Uf8A== Received: by 10.60.20.74 with SMTP id l10mr38982632oee.19.1343925294306; Thu, 02 Aug 2012 09:34:54 -0700 (PDT) Received: from [130.129.19.61] (dhcp-133d.meeting.ietf.org. [130.129.19.61]) by mx.google.com with ESMTPS id hc9sm6310477obc.15.2012.08.02.09.34.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 09:34:53 -0700 (PDT) Message-ID: <501AAC21.80402@gmail.com> Date: Thu, 02 Aug 2012 09:34:41 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: 6man@ietf.org Subject: about LLAs pros/cons static routing - auto/self-configuration of addresses Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 04 Aug 2012 15:46:29 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:35:02 -0000 About LLAs pros/cons static routing, There was an aspect that I dont think I heard during the discussion. When considering the next hop of a static route to be a LLA or a global/ula, one also wonders whether that address is self-configured (fe80, MAC) or autoconfigured with help from outside like SLAAC/DHCP. And knowing that a router would typically not SLAAC for its address then... A preference would be to avoid autoconfigured addresses and use LLAs as nexthop of static permanent routes. Just some thoughts. Alex From aservin@lacnic.net Sun Aug 5 07:37:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B121F84DD for ; Sun, 5 Aug 2012 07:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtvLr-37GsQS for ; Sun, 5 Aug 2012 07:37:49 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id E44F821F84D8 for <6man@ietf.org>; Sun, 5 Aug 2012 07:37:48 -0700 (PDT) Received: from [192.168.1.133] (r186-48-225-212.dialup.adsl.anteldata.net.uy [186.48.225.212]) by mail.lacnic.net.uy (Postfix) with ESMTP id A0608308437; Sun, 5 Aug 2012 11:37:41 -0300 (UYT) Subject: Re: about LLAs pros/cons static routing - auto/self-configuration of addresses Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <501AAC21.80402@gmail.com> Date: Sun, 5 Aug 2012 11:37:40 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <501AAC21.80402@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net X-Mailman-Approved-At: Sun, 05 Aug 2012 12:21:51 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 14:37:49 -0000 I think it was mentioned that LLA may be dependent in the HW = address. Of course, you can configure the MAC address to be the same, = but then the argument of "no-configuration" in favour of LLA is less = significant. =09 IMHO GUA are less susceptible to change (considering that = routers have their addresses manually configured). Regards, as On 2 Aug 2012, at 13:34, Alexandru Petrescu wrote: > About LLAs pros/cons static routing, >=20 > There was an aspect that I dont think I heard during the discussion. >=20 > When considering the next hop of a static route to be a LLA or a > global/ula, one also wonders whether that address is self-configured > (fe80, MAC) or autoconfigured with help from outside like SLAAC/DHCP. > And knowing that a router would typically not SLAAC for its address = then... >=20 > A preference would be to avoid autoconfigured addresses and use LLAs = as > nexthop of static permanent routes. >=20 > Just some thoughts. >=20 > Alex > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From joelja@bogus.com Sun Aug 5 11:17:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC16321F854F for ; Sun, 5 Aug 2012 11:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.307 X-Spam-Level: X-Spam-Status: No, score=-101.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOkwHY3y2fLy for ; Sun, 5 Aug 2012 11:17:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 380B721F854D for <6man@ietf.org>; Sun, 5 Aug 2012 11:17:05 -0700 (PDT) Received: from joels-MacBook-Air.local ([206.191.100.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q75IH41p045583 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <6man@ietf.org>; Sun, 5 Aug 2012 18:17:04 GMT (envelope-from joelja@bogus.com) Message-ID: <501EB8A5.8040609@bogus.com> Date: Sun, 05 Aug 2012 11:17:09 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120717 Thunderbird/15.0 MIME-Version: 1.0 Subject: Re: Fwd: New Version Notification for draft-ietf-6man-impatient-nud-02.txt References: <20120731234819.20604.39168.idtracker@ietfa.amsl.com> <50186F50.8090106@acm.org> In-Reply-To: <50186F50.8090106@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 05 Aug 2012 18:17:04 +0000 (UTC) X-Mailman-Approved-At: Sun, 05 Aug 2012 12:21:51 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 18:17:05 -0000 I just wanted to say that we revved this to remove pointers to expired drafts replacing them instead with a pointer to http://tools.ietf.org/html/rfc6583 and some minor word-smithing. The substance of the draft in particular the suggested algorithm has not changed. On 7/31/12 4:50 PM, Erik Nordmark wrote: > > > > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-6man-impatient-nud-02.txt > Date: Tue, 31 Jul 2012 16:48:19 -0700 > From: > To: > CC: > > > A new version of I-D, draft-ietf-6man-impatient-nud-02.txt > has been successfully submitted by Erik Nordmark and posted to the > IETF repository. > > Filename: draft-ietf-6man-impatient-nud > Revision: 02 > Title: Neighbor Unreachability Detection is too impatient > Creation date: 2012-07-31 > WG ID: 6man > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-6man-impatient-nud-02.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud > Htmlized: http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-impatient-nud-02 > > Abstract: > IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. > That function is very useful when a host has an alternative, for > instance multiple default routers, since it allows the host to switch > to the alternative in short time. This time is 3 seconds after the > node starts probing by default. However, if there are no > alternatives, this is far too impatient. This document specifies > relaxed rules for Neighbor Discovery retransmissions that allows an > implementation to choose different timeout behavior based on whether > or not there are alternatives. > > > > > > The IETF Secretariat > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From wesley.george@twcable.com Mon Aug 6 09:26:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AEC21F8666 for ; Mon, 6 Aug 2012 09:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYaiFi5jszIU for ; Mon, 6 Aug 2012 09:26:43 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8B321F8674 for ; Mon, 6 Aug 2012 09:26:43 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,720,1336363200"; d="scan'208";a="402352558" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 06 Aug 2012 12:09:09 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 6 Aug 2012 12:09:46 -0400 From: "George, Wes" To: Livio Zanol Puppim , "ipv6@ietf.org" Date: Mon, 6 Aug 2012 12:09:44 -0400 Subject: RE: IETF contacts? - Fwd: Reference to historic or obsolated RFCs Thread-Topic: IETF contacts? - Fwd: Reference to historic or obsolated RFCs Thread-Index: Ac1z3vCaqiNHsWY+TT+r6RqS2KdsPAADHhPA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Barry Leiba \(barryleiba@computer.org\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 16:26:44 -0000 Adding 6man, since the RFCs referenced are from that working group. Speaking as the author of 6547, which I wrote to fix the fact that 6164 did= n't formally obsolete 3627 when it changed IETF's guidance on the matter, I= didn't know about the other RFCs that cited 3627 regarding the use of /127= s, mainly because I didn't realize at the time that this page existed: http= ://www.arkko.com/tools/allstats/citations-rfc3627.html I suppose that WGLC and IETF LC reviews should have pointed these omissions= out, but alas we all missed it. That said, each of the references in those other RFCs will point to 3627, a= nd when one looks up 3627, it will note that it is obsoleted by 6547, which= points to the updated guidance in 6164. It's convoluted, but will eventual= ly get you to the right (current) guidance. Question to the WG (and to Barry, given his recent guidance on Errata) - wo= uld it be appropriate to file an errata on 6547 noting the additional RFCs = that it should be updating, is this a matter of issuing a 6547-bis, or does= it simply not matter? Thanks, Wes George > -----Original Message----- > From: Livio Zanol Puppim [mailto:livio.zanol.puppim@gmail.com] > Sent: Monday, August 06, 2012 10:11 AM > To: NANOG list > Subject: IETF contacts? - Fwd: Reference to historic or obsolated RFCs > > Hello guys, > > I've sent the e-mail below to IETF, but I couldn't find a contact e-mail > to address this kind of subject in IETF site. Does anybody knows which > e-mail to send this? > > The contact page from IETF website: > http://www.ietf.org/contact-the-ietf.html > > ---------- Forwarded message ---------- > From: Livio Zanol Puppim > Date: 2012/8/6 > Subject: Reference to historic or obsolated RFCs > To: ietf-info@ietf.org, ietf-action@ietf.org > > > Hello, > > I don't know which contact to send this e-mail, so I'm copying the INFO > and ACTION e-mail... If these are the wrong contact, can you please > point me the correct e-mail? > > Reading the *RFC 5375* I've found references to some RFCs that are > considered Historic, or have been updated. In some cases, this can lead > to a misunderstand of a a section in a RFC. > > For example: > The* RFC 5375* in section *B.2.2* states that we should avoid using /127 > IPv6 prefix, but* RFC 6164* clearly says that we can use /127 prefix for > Inter-Router links. In fact, the *RFC 6547*, moves the *RFC > 3627*(referenced by the > * RFC 5375* in the above section) to Historic status. > > If my point of view is indeed correct, I think that everytime a new RFC > is published that proposes an *Update* to another RFC, or *Obsoletes* > another RFC or moves a RFC to *Historic *status, the team responsible > for it's creation needs to read every reference to that RFC and request > changes in order to avoid this kind of misunderstanding. This is very > important to guys like me, that only reads the RFCs. > > the section from RFC 5375 > http://tools.ietf.org/html/rfc5375#appendix-B.2.2 > > " > > > B.2.2 . /127 > Addresses > > The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 > > [RFC3021 ], is not valid and > should be strongly discouraged as > documented in RFC 3627 > [RFC3627 ]. > > " > > -- > []'s > > L=EDvio Zanol Puppim > > > > -- > []'s > > L=EDvio Zanol Puppim This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From sm@resistor.net Mon Aug 6 23:03:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC6321F8647 for ; Mon, 6 Aug 2012 23:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0k+4pBVh6oU for ; Mon, 6 Aug 2012 23:03:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E475721F8661 for ; Mon, 6 Aug 2012 23:03:39 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7763QHY014046; Mon, 6 Aug 2012 23:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1344319411; bh=hX+LviHklX3w2P+chpKba8J7tYjEAiChpXXmPrKxvxw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TF+MDq9YDpvmDtitxLc9RE9bUfAuj4lCPKIOVU4UC20rDgKGQzOfvNAw3j4m9Kki1 l9eNXT63mK/yQPLdd5qi2fdIUnjkuvIGFyXP7fZ7EL/Ve9VmJjTJz19HBDaJZ/6myR fnkVAICr2CMv+XCClgQWlYqHEGrGUt+blrcoqMxs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1344319411; i=@resistor.net; bh=hX+LviHklX3w2P+chpKba8J7tYjEAiChpXXmPrKxvxw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vfrAgFMxrRUsV+J6XMIOPEGmrmYQQxKAFNNqGx8NEB4uRArEFguQQDn0IqAQFy4lV VhMp6GxcfRjl2N7nh9HgC9z1C/P4h+HeNuI2Y0+RyLEsycCiLeHt4CezzdQBplOx66 3YWJBhhS9fk5mqHeqw/sYreRAlo311w38zj5/gJw= Message-Id: <6.2.5.6.2.20120806224316.099b3718@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Aug 2012 23:03:26 -0700 To: "George, Wes" From: SM Subject: RE: IETF contacts? - Fwd: Reference to historic or obsolated RFCs In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 06:03:43 -0000 At 09:09 06-08-2012, George, Wes wrote: >Question to the WG (and to Barry, given his recent guidance on >Errata) - would it be appropriate to file an errata on 6547 noting >the additional RFCs that it should be updating, is this a matter of >issuing a 6547-bis, or does it simply not matter? RFC 6547 moves RFC 3627 to Historic. I don't see any reason to reopen it with a -bis. Please see https://www.ietf.org/iesg/statement/rfc-metadata-errata.html Regards, -sm From internet-drafts@ietf.org Tue Aug 7 00:28:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968BC11E808A; Tue, 7 Aug 2012 00:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQYvrLAgwYlW; Tue, 7 Aug 2012 00:28:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7891921F8600; Tue, 7 Aug 2012 00:28:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-udpchecksums-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807072811.20888.40824.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2012 00:28:11 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 07:28:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks P.F. Chimento Magnus Westerlund Filename : draft-ietf-6man-udpchecksums-03.txt Pages : 12 Date : 2012-08-07 Abstract: This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance of IPv6 in the use case when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums on IPv6 packets used to carry tunnel protocols and thereby improves the efficiency of the traversal of firewalls and other network middleboxes by such protocols. We describe how the IPv6 UDP checksum requirement can be relaxed in the situation where the encapsulated packet itself contains a checksum, the limitations and risks of this approach, and defines restrictions on the use of this relaxation to mitigate these risks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpchecksums-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Tue Aug 7 00:37:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBFA11E80A6 for ; Tue, 7 Aug 2012 00:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RksEXiJ9iazF for ; Tue, 7 Aug 2012 00:37:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DD8F311E809C for ; Tue, 7 Aug 2012 00:37:33 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-35-5020c5bcde71 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AF.33.12641.CB5C0205; Tue, 7 Aug 2012 09:37:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Tue, 7 Aug 2012 09:37:32 +0200 Message-ID: <5020C5BB.9020006@ericsson.com> Date: Tue, 7 Aug 2012 09:37:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-udpchecksums-03.txt References: <20120807072811.20888.40824.idtracker@ietfa.amsl.com> In-Reply-To: <20120807072811.20888.40824.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3VnfPUYUAg0XPxS1enn3P5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNtPXAtmyla8vtnC1MC4QLyLkZNDQsBEouHwCSYIW0ziwr31 bF2MXBxCAqcYJTbNbmSCcJYxSjQ8OwqU4eDgFdCWeHbSFqSBRUBFYvPBLnYQm03AQuLmj0Y2 EFtUIFDi29bjrCA2r4CgxMmZT1hAbBEge/uDH2C2sICNxLyWm2D1QgKOEmcnNoLFOQWcJE5s n8gMskpCQFLi9oEUkDCzgJ7ElKstjBC2vETz1tnMEK3aEg1NHawTGAVnIdk2C0nLLCQtCxiZ VzEK5yZm5qSXm+ulFmUmFxfn5+kVp25iBIbkwS2/DXYwbrovdohRmoNFSZxXT3W/v5BAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGlSvuhPKU3EmsWTf15YWtay9Xae57X9oTkL//e/aB7O2T C2qyXhq8ebBJf1l/k4jji0OsfgJWt+vuLjuzZoWcjJbAPI5Y1WrhiSlPbtVFh70QXVWQrVz6 t3+a/1XLOW+fhh9d3bV1olpb086yleZZlSZzPvWtT+ku+fhsw/WiDRcnzCmZV3CtSomlOCPR UIu5qDgRAOBBBVsXAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 07:37:35 -0000 WG, I have helped Philip and Marshall to get an updated version addressing the WG last call comments submitted. This version addresses mine and Gorry's comments to the mailing list earlier this year. During the editing and subsequent review Gorry spotted an additional document structure issue with normative text in a discussion section. To address these a bit more changes where needed. As can be seen in the diff there is quite a number of changes: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-udpchecksums-03 Based on that there some changes to the formulation of normative statements, although not their spirit, I request that the WG chairs do initiate a last call on this new version to confirm the WG's desire to request publication of this version. Considering that a number of I-Ds have dependency on this document I would request that the people interested in those I-Ds do review this. Cheers Magnus Westerlund On 2012-08-07 09:28, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : UDP Checksums for Tunneled Packets > Author(s) : Marshall Eubanks > P.F. Chimento > Magnus Westerlund > Filename : draft-ietf-6man-udpchecksums-03.txt > Pages : 12 > Date : 2012-08-07 > > Abstract: > This document provides an update of the Internet Protocol version 6 > (IPv6) specification (RFC2460) to improve the performance of IPv6 in > the use case when a tunnel protocol uses UDP with IPv6 to tunnel > packets. The performance improvement is obtained by relaxing the > IPv6 UDP checksum requirement for suitable tunneling protocol where > header information is protected on the "inner" packet being carried. > This relaxation removes the overhead associated with the computation > of UDP checksums on IPv6 packets used to carry tunnel protocols and > thereby improves the efficiency of the traversal of firewalls and > other network middleboxes by such protocols. We describe how the > IPv6 UDP checksum requirement can be relaxed in the situation where > the encapsulated packet itself contains a checksum, the limitations > and risks of this approach, and defines restrictions on the use of > this relaxation to mitigate these risks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-udpchecksums-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From brian@innovationslab.net Tue Aug 7 03:48:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C479121F86A4 for ; Tue, 7 Aug 2012 03:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0jNRRqpt0w6 for ; Tue, 7 Aug 2012 03:48:48 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D5FBB21F86A2 for ; Tue, 7 Aug 2012 03:48:48 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 83A61880DB for ; Tue, 7 Aug 2012 03:48:48 -0700 (PDT) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 445D4130017 for ; Tue, 7 Aug 2012 03:48:48 -0700 (PDT) Message-ID: <5020F2A2.804@innovationslab.net> Date: Tue, 07 Aug 2012 06:49:06 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IETF contacts? - Fwd: Reference to historic or obsolated RFCs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 10:48:49 -0000 On 8/6/12 12:09 PM, George, Wes wrote: > Adding 6man, since the RFCs referenced are from that working group. > > Speaking as the author of 6547, which I wrote to fix the fact that > 6164 didn't formally obsolete 3627 when it changed IETF's guidance on > the matter, I didn't know about the other RFCs that cited 3627 > regarding the use of /127s, mainly because I didn't realize at the > time that this page existed: > http://www.arkko.com/tools/allstats/citations-rfc3627.html I suppose > that WGLC and IETF LC reviews should have pointed these omissions > out, but alas we all missed it. > > That said, each of the references in those other RFCs will point to > 3627, and when one looks up 3627, it will note that it is obsoleted > by 6547, which points to the updated guidance in 6164. It's > convoluted, but will eventually get you to the right (current) > guidance. > > Question to the WG (and to Barry, given his recent guidance on > Errata) - would it be appropriate to file an errata on 6547 noting > the additional RFCs that it should be updating, is this a matter of > issuing a 6547-bis, or does it simply not matter? I am not sure what an errata statement would say in this context. It is not the responsibility of 6164 to fix all references to 3627. Regards, Brian From bob.hinden@gmail.com Tue Aug 7 14:37:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4321F867D for ; Tue, 7 Aug 2012 14:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIy4CACKP9zj for ; Tue, 7 Aug 2012 14:37:51 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9EE121F866D for ; Tue, 7 Aug 2012 14:37:51 -0700 (PDT) Received: by ghbg16 with SMTP id g16so110742ghb.31 for ; Tue, 07 Aug 2012 14:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=qQRb5v7yIZDD365XC2Vfr951+7B/EOH6iAK3tLdrXdU=; b=UKP+pg8KsDmFHrtENp2Qvlxbb2VEThfqUrvxhJ1oYaxDhmKRpjI5FTDUQWX1oCAKOm eFlbotgle+F570Sr+sdpPWiWWKKrJeYV1LrlL8U6cIfxdG8nThJxsJMn+vP3q8qK7AM9 5rQ4xUpQ1IwIIbzT/a1Y45qg4yPuxylQpZw0xijpaa8walr2quUPDeOuO3J7O/lDCCyH b9P0Dfq2hwwzQBWI51oPN+b07dlz19fnXYDuTRDBAujmcGHzuCYfTyx2L2MR60QGTuuA j42SkIeqKtWERQJ7ha5oFpwoXeGzNosWdE3RxrwsWC6Ho/yfT2fM+rU2DNgYgIs+BfF7 p6yQ== Received: by 10.66.87.66 with SMTP id v2mr28907470paz.71.1344375470945; Tue, 07 Aug 2012 14:37:50 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPS id op10sm8463188pbc.75.2012.08.07.14.37.49 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 14:37:50 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Tue, 7 Aug 2012 14:37:49 -0700 Message-Id: To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1280) X-Mailer: Apple Mail (2.1280) Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:37:52 -0000 All, This message starts a one week 6MAN Working Group on advancing: Title : UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks P.F. Chimento Magnus Westerlund Filename : draft-ietf-6man-udpchecksums-03.txt Pages : 12 Date : 2012-08-07 http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-04 as Proposed Standard. An earlier working group last call was completed = on May 3, 2012. Due to the number of changes introduced to resolve = issues raised during that last call and the time since the first last = call, this second last call is being done. Substantive comments and statements of support for advancing this = document should be directed to the mailing list. Editorial suggestions = can be sent to the authors. This last call will end on August 14, 2012. Regards, Bob Hinden and Ole Tr=F8an From dthaler@microsoft.com Tue Aug 7 15:44:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DFA21F8687 for ; Tue, 7 Aug 2012 15:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.682 X-Spam-Level: X-Spam-Status: No, score=-103.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1CX-G9RVRSZ for ; Tue, 7 Aug 2012 15:44:25 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADA321F846B for ; Tue, 7 Aug 2012 15:44:25 -0700 (PDT) Received: from mail171-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 22:44:24 +0000 Received: from mail171-co1 (localhost [127.0.0.1]) by mail171-co1-R.bigfish.com (Postfix) with ESMTP id AD4D13C035E; Tue, 7 Aug 2012 22:44:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zf7Iz9371I1b0bI542M1432Id4c4mzz1202hzz8275ch1033IL8275bh8275dh186Mz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail171-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail171-co1 (localhost.localdomain [127.0.0.1]) by mail171-co1 (MessageSwitch) id 1344379462972806_30864; Tue, 7 Aug 2012 22:44:22 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.236]) by mail171-co1.bigfish.com (Postfix) with ESMTP id E21F064004A; Tue, 7 Aug 2012 22:44:22 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 22:44:22 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 7 Aug 2012 22:44:08 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Tue, 7 Aug 2012 15:44:07 -0700 From: Dave Thaler To: Brian E Carpenter Subject: RE: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Thread-Topic: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] Thread-Index: AQHNX2DzeUGxz0UIhkC9N9TBFxf2fZcmBI2AgACAdACAAC6sAIACO/YAgABj2oCAACiUgIAAA14AgAD2JYCAAf+tsIAippeQ Date: Tue, 7 Aug 2012 22:44:07 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B745966@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4FFD71D7.4070209@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6BF582@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <4FFF29E2.6090909@viagenie.ca> <6.2.5.6.2.20120712152812.082ba6f8@resistor.net> <500130D4.7050604@gmail.com> <50018497.2050809@viagenie.ca> <5001A6A1.4020109@gmail.com> <5001A974.3020908@viagenie.ca> <500277EF.9040302@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B6F535A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B6F535A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:44:29 -0000 FYI, as another data point that might be added to the appendix of alternati= ves and things that are already out there, would be using 's' as the separator = rather than '-'. That's the character that's used by ipv6-literal.net names. See http://ipv6-literal.com/ for a converter, and http://technet.microsoft.com/en-us/library/bb726965.aspx for one place the syntax is doc'ed. You'll have to search for it on the page though, but to = save you the trouble I'll quote it here: > An ipv6-literal.net name can be used in services or applications that do = not > recognize the syntax of normal IPv6 addresses.=20 >=20 > To specify an IPv6 address within the ipv6-literal.net name, convert the= =20 > colons (:) in the address to dashes (-). For example, for the IPv6 addres= s=20 > 2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net=20 > name is 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net. To specify a > zone ID (also known as a scope ID), replace the "%" used to separate the > IPv6 address from the zone ID with an "s". For example to specify the > destination fe80::218:8bff:fe17:a226%4, the name is > fe80--218-8bff-fe17-a226s4.ipv6-literal.net. The above syntax was designed to be usable even by applications that didn't support [] syntax in URIs. -Dave > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Monday, July 16, 2012 2:56 PM > To: Brian E Carpenter; ipv6@ietf.org > Subject: RE: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] >=20 > I'm ok with the updated text Brian posted. >=20 > To comment on the other points others raised: >=20 > * I agree that we should define either '%' or '-' as being the canonical = form. > RFC 5952 covers issues with not having one, and defines a canonical fo= rm > for IPv6 literals, but does not mention the zone id at all. If we wa= nt safe > cut-and-paste, then '-' needs to be defined as canonical (i.e., what y= ou > output). However, you won't get cut-and-paste to things that haven't > been updated to support it. So one conclusion you might draw is that > you can't get cut-and-paste *everywhere* within our lifetime, and you > should > just get used to it. And if you're one of the people who draws that > conclusion > then you might even go so far as to question the whole document, which > seems to be where Juergen is coming from. >=20 > * Brian writes: "What we do *not* say is to recommend or suggest that all > tools that support RFC 4007 should be updated. Should we also add that= ?" >=20 > If we really care about cut-and-paste, then yes. Which is why this > document > is so difficult to get benefit from, since it requires changing so man= y things. > (See last paragraph of [RFC5218] section 2.1.1.) >=20 > * Juergen writes: "Changing all our standards to support "-" and then wai= ting > years for this to be supported by all the system tools is from a user= s' > perspective pretty much a disaster." >=20 > I'm actually fairly sympathetic to that point of view. >=20 > The status quo without this document is basically that you cannot use > zone IDs in URIs, although some apps and OSs support URI-like strings > that do allow them but it may vary by app and OS. With this document= , > the story is that you can use them in some (updated) applications and > thus sometimes you can get cut-and-paste. That sounds like a small > benefit to get from requiring changes to all IPv6 literal (including i= n URIs) > parsers/generators. This doesn't seem to bode well from an RFC 5218 > analysis standpoint. >=20 > * Juergen writes: " If it were that simple, we could simply recommend tha= t > browsers should be lenient and accept the %en1 format. The question i= s > really whether Internet Explorer people would do so and whether Firef= ox > people would go back to support what they apparently did before." >=20 > As I mentioned in my original email, it's not just IE 7 and up, it's a= lso the > OS APIs so it's pretty pervasive (again, not on the wire just in APIs = within > the host) so I think you mean "whether IE and Windows people would do > so". > I think it's probably safe to assume the answer is "No" because it may= result > in breaking applications. That's not something that's worth it just = to get > "cut-and-paste" which is nowhere near as important as app compat. >=20 > -Dave >=20 >=20 > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > Of Brian E Carpenter > > Sent: Sunday, July 15, 2012 12:58 AM > > To: ipv6@ietf.org > > Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt] > > > > Without consulting my co-author, here's my personal suggestion for a > > change to the draft. There's just time to submit an update before the > > cutoff, if people respond immediately. > > > > OLD > > In recent years, web browsers have evolved considerably and now > > accept and parse many forms of input that are not a formal URI. > > Examples of this include host names, search items, bookmarks, search > > history, etc. For example the Google Chrome browser now calls the > > "address bar" the "omnibox" [chrome]. The authors believe it is > > feasible, and very convenient for users, if browsers also allow (in > > addition to the formal URI syntax defined in this document) a syntax > > that will enable cut and paste. For example: > > > > http://[fe80::a%en1] > > > > It seems that modern browsers can be adapted to parse this because i= t > > is inside of the "[" "]"'s. This would permit the output of command= s > > like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser > > address bar. Consequently this document recommends that browsers > > support this syntax in addition to the formal URI syntax defined > > above. > > > > NEW > > > > In recent years, web browsers have evolved considerably and now > > accept and parse many forms of input that are not a formal URI. > > Examples of this include host names, search items, bookmarks, search > > history, etc. For example the Google Chrome browser now calls the > > "address bar" the "omnibox" [chrome]. Thus, it seems that browsers > > can take a pragmatic approach to literal addresses including ZoneIDs= . > > Unfortunately there is no way to resolve the discrepancy between > > the two approaches mentioned above (raw "%" versus "%25") and > > therefore we recommend general implementation of the new "-" syntax > > defined by this document. This will allow simple "cut and paste" > > between tools such as "ping6" and browser address bars. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From barryleiba@gmail.com Tue Aug 7 21:39:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BEB11E80EA for ; Tue, 7 Aug 2012 21:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOn+9kxQgxc0 for ; Tue, 7 Aug 2012 21:39:30 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD3DF11E80E2 for ; Tue, 7 Aug 2012 21:39:29 -0700 (PDT) Received: by ghbg16 with SMTP id g16so386753ghb.31 for ; Tue, 07 Aug 2012 21:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XAbVce/U/3tUwKXbs8esrTfuHHgIE2uWkCM5XjTMsA8=; b=FHhbBbHIHjujQJi2jrlPdYL7Q44TmtvY/T0dHFH5XXj1MkX2xijsf1UGVztm1Sxzgb OOW0cPjaJwqcO6Yy+s57zYXNC8HEn4HfBvmA0MYZs/fUL0ZDtwgGqnET/fq5CMNj9E3D nzMBK2ZgxCO9LSAvc5NSqxCt5rtrVmRoRbnO0In+OCjLnjL7cQPRel6WA0iONT4zSd7M XMl1iWEBbZxE5uF1vH4RpPMjT1jJYb9s/BL5ZPVzOVXS1VRh8e3hx4uI/bi9lMwdYBVM GVnNA5NX02/N5OO2Pd03jBUpE26IyjCkp3m30zKSionc1zvtPzYvKyhGvFnBl4OGfNJ5 b9KA== MIME-Version: 1.0 Received: by 10.66.76.135 with SMTP id k7mr30943674paw.2.1344400769035; Tue, 07 Aug 2012 21:39:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.68.64.103 with HTTP; Tue, 7 Aug 2012 21:39:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Aug 2012 00:39:28 -0400 X-Google-Sender-Auth: mCHnBORl9wVWoJWje9i5jKq5ozg Message-ID: Subject: Re: IETF contacts? - Fwd: Reference to historic or obsolated RFCs From: Barry Leiba To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" , Livio Zanol Puppim X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 04:39:36 -0000 Hi, guys. > Question to the WG (and to Barry, given his recent guidance on Errata) - would > it be appropriate to file an errata on 6547 noting the additional RFCs that it should > be updating, is this a matter of issuing a 6547-bis, or does it simply not matter? This has come up with some other documents, as well (RFCs 5375 and 6164). I'm checking on this with the rest of the IESG and the RFC Editor, but here's what I think: As I understand it, we don't need to use the errata system for this. The updates/obsoletes information is in the RFC metadata. We could process this as an IESG management item to update the metadata in the RFCs to indicate what updates what. From a procedural point of view, I'm not sure whether we would need (or want) to last-call that action before we did it. Barry From cheshire@apple.com Thu Aug 9 14:32:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA4B21F86E2 for ; Thu, 9 Aug 2012 14:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwmNPG1TwfYb for ; Thu, 9 Aug 2012 14:32:20 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2147421F86B4 for ; Thu, 9 Aug 2012 14:32:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M8I00D4CBROQOAA@mail-out.apple.com> for ipv6@ietf.org; Thu, 09 Aug 2012 14:32:19 -0700 (PDT) X-AuditID: 11807134-b7f866d000002583-7f-50242c6300ea Received: from [17.193.13.41] (chesh1.apple.com [17.193.13.41]) by relay14.apple.com (Apple SCV relay) with SMTP id EE.36.09603.36C24205; Thu, 09 Aug 2012 14:32:19 -0700 (PDT) Message-id: From: Stuart Cheshire Subject: draft-ietf-6man-uri-zoneid-02 Date: Thu, 09 Aug 2012 14:31:24 -0700 To: ipv6@ietf.org X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUieJBXUzdZRyXAYNt1FYut7/exWbRd3Mdk cWnFEVaLl2ffMzmweOycdZfdY8mSn0werTv+sgcwR3HZpKTmZJalFunbJXBl9H97zlJwnKNi 0brfjA2Md9m6GDk5JARMJHoeHmOCsMUkLtxbDxTn4hAS2Mgo8eLLVlaQBK+AkcTVyVPZuxg5 OJgFXCQWTsmDCNtITDt6G2wOs0C9xON9n1ggbHmJ7W/nMIPYbAJaEi8+X2EDaRUWUJP4etEP JMwioCKx+PFXsOkiAoIS2x/8YIE4QU7i8OlXjBMYeWchWTwLYfEsJAsWMDKvYhQsSs1JrDQ0 0UssKMhJ1UvOz93ECAqvhkKTHYwHf/IfYhTgYFTi4RUQUgkQYk0sK67MPcQowcGsJMKb8kI5 QIg3JbGyKrUoP76oNCe1+BCjNAeLkjhv7w6lACGB9MSS1OzU1ILUIpgsEwenVAOjZsvdoi7F iK6uElnV72/4uRaWu/rZJUquYph7S9jq155F/Ku/LbONUp7xQTM0XPaWzbnUgqDtcRY5RbW+ uo5NO5lUG2erGMQ7C4r9n6lV3Divm1kijunfurmFweqtVy2/CXBc2d7+QvhQ0wKju91d0XNs RAwi+619jrtsj/yuZn0kcmbyPiWW4oxEQy3mouJEALDuHzMrAgAA Cc: Bob Hinden , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:32:21 -0000 At the meeting in Vancouver, Dave Thaler made a point that I found convincing: Where is the character set for IPv6 zone IDs specified? If we accept that future interface names might include non-roman characters, then we have to assume that to allow safe unambiguous use in URIs, interface names have to undergo escaping. And if the interface name itself is going to be escaped using URI "% xx" notation, then why not escape the '%' the same way? This argues in support of what Microsoft already did: Encode '%' as "% 25". It's not my favourite outcome, but based on Dave Thaler's comment, it's the one that gets my vote. In the spirit of "be liberal with what you accept" the doc should also advocate that URI parsers are forgiving about accepting bare '%' signs -- i.e. a '%' not followed by two valid hex characters is left untouched. This lets a human user copy-and-paste "fe80::a%en1" from a "ping" command and have it work, though the strictly correct form (which URI generators should output) remains "fe80::a%25en1". Stuart Cheshire From brian.e.carpenter@gmail.com Fri Aug 10 00:32:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B4821F8608 for ; Fri, 10 Aug 2012 00:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.477 X-Spam-Level: X-Spam-Status: No, score=-101.477 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtnihBekSibo for ; Fri, 10 Aug 2012 00:32:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7AA21F8604 for ; Fri, 10 Aug 2012 00:32:01 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so743009wgb.13 for ; Fri, 10 Aug 2012 00:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NFJuP6sjdLsbkzyHWz2r/k4MQKr5iGALD06V66UOyxA=; b=wC+xYopksVCnpIHY99jxMdnEg1dwx5Eu4D02zgw2kqRfhTE+OpdCnhA31kDjf/ML7q ba55FZF1XoIa7t1n0iAHJnZHLsHTy0yDEgJ4KPwWXKiXxJ6rXxKVkPSyyKvCPSlQTQVf bCvIBtBRfu6iXgmwxxHsFx025SHUs9KvYsz3ZzLe0hm0hZVwDJIdyNKHcCQQaALH/dfQ q2SOSsdR5k6oc18p3UVKqsF7vbIl2grj53aOIh5Zov0UWCukIT+e6z8qkpIEU5BlT/3F OgTaUoT7U+3X5MQPsSNqBwNaHvi1FgbQ+jp1YS2rXEzIjpeDoLWBNlMhvxeRoTgk8R8W Qsvg== Received: by 10.216.144.234 with SMTP id n84mr1145017wej.78.1344583921164; Fri, 10 Aug 2012 00:32:01 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-58.as13285.net. [2.102.218.58]) by mx.google.com with ESMTPS id cl8sm6169150wib.10.2012.08.10.00.31.58 (version=SSLv3 cipher=OTHER); Fri, 10 Aug 2012 00:32:00 -0700 (PDT) Message-ID: <5024B8F9.5090908@gmail.com> Date: Fri, 10 Aug 2012 08:32:09 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stuart Cheshire Subject: Re: draft-ietf-6man-uri-zoneid-02 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , ipv6@ietf.org, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:32:02 -0000 Stuart, On 09/08/2012 22:31, Stuart Cheshire wrote: > At the meeting in Vancouver, Dave Thaler made a point that I found > convincing: > > Where is the character set for IPv6 zone IDs specified? RFC 4007 doesn't do so, but can be read to imply ASCII. draft-ietf-6man-uri-zoneid-02 is explicit that it refers to the URI character set, which is ASCII: A SHOULD contain only ASCII characters classified in RFC 3986 as "unreserved". But it allows percent encoding in a URI, which is necessary because of the SHOULD: ZoneID = 1*( unreserved / pct-encoded ) > If we accept > that future interface names might include non-roman characters, then we > have to assume that to allow safe unambiguous use in URIs, interface > names have to undergo escaping. If we want to internationalise the ZoneID, that would be a whole other discussion. > And if the interface name itself is going to be escaped using URI "%xx" > notation, then why not escape the '%' the same way? My impression is that this WG has already objected to that, which is why we ended up with the current proposal. I leave the next step to the WG Chair. Brian > This argues in support of what Microsoft already did: Encode '%' as "%25". > > It's not my favourite outcome, but based on Dave Thaler's comment, it's > the one that gets my vote. > > In the spirit of "be liberal with what you accept" the doc should also > advocate that URI parsers are forgiving about accepting bare '%' signs > -- i.e. a '%' not followed by two valid hex characters is left > untouched. This lets a human user copy-and-paste "fe80::a%en1" from a > "ping" command and have it work, though the strictly correct form (which > URI generators should output) remains "fe80::a%25en1". > > Stuart Cheshire > > From internet-drafts@ietf.org Fri Aug 10 03:39:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CF421F8685; Fri, 10 Aug 2012 03:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGv1TS94lYTG; Fri, 10 Aug 2012 03:39:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3121F866B; Fri, 10 Aug 2012 03:39:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120810103916.17649.29017.idtracker@ietfa.amsl.com> Date: Fri, 10 Aug 2012 03:39:16 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 10:39:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Processing of IPv6 "atomic" fragments Author(s) : Fernando Gont Filename : draft-ietf-6man-ipv6-atomic-fragments-01.txt Pages : 13 Date : 2012-08-10 Abstract: The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-atomic-fragments-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcr+ietf@sandelman.ca Fri Aug 10 08:55:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3821F8634 for ; Fri, 10 Aug 2012 08:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX+H47OiREe3 for ; Fri, 10 Aug 2012 08:55:31 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id A6BDD21F8629 for ; Fri, 10 Aug 2012 08:55:31 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id B21572028E; Fri, 10 Aug 2012 12:08:25 -0400 (EDT) From: Michael Richardson To: ipv6@ietf.org Subject: Re: draft-ietf-6man-uri-zoneid-02 In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Cc: Bob Hinden , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:55:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Stuart" =3D=3D Stuart Cheshire writes: Stuart> This argues in support of what Microsoft already did: Encode Stuart> '%' as "% 25".=20 okay. May a browser process the %-escaped UTF-8 in the interface name for the purpose of display them?=20=20 If it does that, and a user then copies and pastes the address into the ping command, presumeably, the copy buffer contains the UTF-8, so the result that the parser (in the ping) sees the bare % as well? (this is just supporting that you say that the parse must be tolerant of a bare %) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCUu64qHRg3pndX9AQJHYQP/W6apm7c0EGkBGme94t6QxlR31aoy/7N/ iPUMeO8lpf5rz+717hcorXcsrYVMgBbeGi/OZFugM7wSAY0AFFF5IXF5TWGt4pB+ p9vJGwmemrO+ritixopnCV1q/PXdDgfi2fleJ7dRz2XWH8N8XYDgDOarcZNZ/oa5 ckKm0ajx2wY= =ZYsq -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Fri Aug 10 09:02:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5D221F86D6 for ; Fri, 10 Aug 2012 09:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.481 X-Spam-Level: X-Spam-Status: No, score=-101.481 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPTEZIaGwhA4 for ; Fri, 10 Aug 2012 09:02:48 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7034121F86C7 for ; Fri, 10 Aug 2012 09:02:48 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1158210wib.13 for ; Fri, 10 Aug 2012 09:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9uu9JPFogBLZ9mnLb4FLJoZsYnYQdrQWv8vvWnPntUs=; b=bc3pnB76qBK3ElXXcQcxW/PN1TnPjwYzmX7AOOvzjCyHSS6OullbgiO/r0JpEptWGS dshqCVBD53nRpApPAwlkW6bNIReThG0/jLkRMd30k8dLqqeul00tOd0kuhCMC6yq7B+9 ex6NZ3OkgNc4FXq5biL2l7VGfppEIGVRanqWhOPSl5uTnd374JEF3OynyiyrzLmpx+Cv nUOuD1+dniI/D4kygcj5Hqtiz15SEaaToCRLAuvpKPrvCu5Qj/LM8yzufAv6oxw4T4zh N8bs+ltdhS+wtnYBA4ss4pLSKI3CseIhIsFH1ilIJqGtCrZQTnwKahOujSAGLN6mV/xp Z1Eg== Received: by 10.217.3.1 with SMTP id q1mr1770089wes.38.1344614567578; Fri, 10 Aug 2012 09:02:47 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-58.as13285.net. [2.102.218.58]) by mx.google.com with ESMTPS id dc3sm8471336wib.7.2012.08.10.09.02.46 (version=SSLv3 cipher=OTHER); Fri, 10 Aug 2012 09:02:46 -0700 (PDT) Message-ID: <502530B1.8000506@gmail.com> Date: Fri, 10 Aug 2012 17:02:57 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson Subject: Re: draft-ietf-6man-uri-zoneid-02 References: <21561.1344614123@obiwan.sandelman.ca> In-Reply-To: <21561.1344614123@obiwan.sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , ipv6@ietf.org, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:02:49 -0000 > (this is just supporting that you say that the parse must be tolerant of > a bare %) First please solve the mystery of how such a parser can tell whether %251 is an escaped "%1" or an unescaped "%251". From fred@cisco.com Fri Aug 10 15:17:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF02721F85C5 for ; Fri, 10 Aug 2012 15:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.307 X-Spam-Level: X-Spam-Status: No, score=-110.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DfbWX+bCJRj for ; Fri, 10 Aug 2012 15:17:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1895A21F85C4 for ; Fri, 10 Aug 2012 15:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=653; q=dns/txt; s=iport; t=1344637045; x=1345846645; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Sm7uVqjt4U9O3qOT0Z1jOFbEhVtT+xkT+9sL5+tfIrE=; b=fCFVqEudZgwBbfSuihwEM4ejbcbferJRquRULLGE/n0uwapi4Ee7y4bn 7du66OydKh3MAXffawIK62RytCpNv6OK7j+ZQziDvtpSWTgbqVvALoahM SpsW7fpivk7kJylHVz2/XqgBJrN3HfDkLhZaXAk81lDlfiB22LvZjbJPp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMx4JVCtJXG+/2dsb2JhbABEuXeBB4InEgF4AYEAJwQ1h2uWSYEooAWRE2ADlUmOKYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,748,1336348800"; d="scan'208";a="110265766" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 10 Aug 2012 22:17:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7AMHGd9010686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 Aug 2012 22:17:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 17:17:15 -0500 From: "Fred Baker (fred)" To: "ipv6@ietf.org 6man" Subject: DAD question Thread-Topic: DAD question Thread-Index: AQHNd0XlCeAhXXPBcEK2v5tAiE4SZQ== Date: Fri, 10 Aug 2012 22:17:15 +0000 Message-ID: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19102.001 x-tm-as-result: No--32.506600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:17:25 -0000 Call this "making sure I'm on the same page as anyone else"=85 RFC 4941 describes privacy addresses, and RFC 4291 describes an EID based o= n a MAC Address. RFC 4862 describes stateless address autoconfiguration, an= d uses RFC 4861's duplicate address detection mechanism. My question is: what happens if any of them discovers that it has created a= n address that is already in use in the network? There would appear to be two options:=20 (1) "ah, OK, I guess I didn't really want to talk today" (2) Following RFC 4941, guess again until one creates a unique address Is it fair to assume that implementations do DAD and follow (2)?= From jared@puck.nether.net Fri Aug 10 15:19:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A45811E8087 for ; Fri, 10 Aug 2012 15:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkJGZlvrIqG6 for ; Fri, 10 Aug 2012 15:19:25 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED421F85D0 for ; Fri, 10 Aug 2012 15:19:25 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q7AMJLie018447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 18:19:22 -0400 Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Jared Mauch In-Reply-To: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> Date: Fri, 10 Aug 2012 18:19:21 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 10 Aug 2012 18:19:22 -0400 (EDT) Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:19:26 -0000 On Aug 10, 2012, at 6:17 PM, Fred Baker (fred) wrote: > Is it fair to assume that implementations do DAD and follow (2)? This is the logical thing that I personally would do.. - Jared From fgont@si6networks.com Fri Aug 10 16:09:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA3B21F8517 for ; Fri, 10 Aug 2012 16:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZxv+xuuT1uX for ; Fri, 10 Aug 2012 16:09:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 01F3A21F8508 for ; Fri, 10 Aug 2012 16:09:54 -0700 (PDT) Received: from [190.245.182.195] (helo=[192.168.1.128]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SzyKx-0006UN-PH; Sat, 11 Aug 2012 01:09:48 +0200 Message-ID: <50259461.8090802@si6networks.com> Date: Fri, 10 Aug 2012 20:08:17 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Fred Baker (fred)" Subject: Re: DAD question References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> In-Reply-To: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:09:55 -0000 Hi, Fred, On 08/10/2012 07:17 PM, Fred Baker (fred) wrote: > Call this "making sure I'm on the same page as anyone else"… > > RFC 4941 describes privacy addresses, and RFC 4291 describes an EID > based on a MAC Address. RFC 4862 describes stateless address > autoconfiguration, and uses RFC 4861's duplicate address detection > mechanism. > > My question is: what happens if any of them discovers that it has > created an address that is already in use in the network? For traditional SLAAC (i.e. EID based on the MAC address), SLAAC simply fails. IIRC, you get different results depending on whether DAD fails for a link-local address, or it fails for a non-link-local address. For the former, you may need to reboot your system. For the later, I seem to recall that some systems "perform DAD", but do not care if DAD actually fails. Simplest answer: "Try it": Run na6 (http://www.si6networks.com.ar/tools) as follows: # ./na6 -i eth0 -j :: -c -o -e -L -vv where: "-i eth0": your NIC "-j ::": tells the tool to only respond to packets with the Src Addr set to the unspec addr (i.e., DAD packets) "-c": Set the solicited flag "-o:" Set the override flag (shouldn't matter in this case) "-L": Listen mode (wait for incoming ns'es) "-vv": Be very verbose > There would appear to be two options: (1) "ah, OK, I guess I didn't > really want to talk today" This is what all implementations do for tradicional SLAAC (when they do honor SLAAC --see above). > (2) Following RFC 4941, guess again until > one creates a unique address > > Is it fair to assume that implementations do DAD and follow (2)? Might be fair to assume this for the temporary address, but it is certainly not realistic to assume this for the traditional SLAAC address (*) (**). (*) Microsoft Windows allegedly replace the traditional SLAAC addresses with a RFC4941-based scheme that simply does not cycle the addresses over time -- hence "(2)" might apply to Windows. (**) Will head in this direction for draft-ietf-6man-stable-privacy-addresses Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dthaler@microsoft.com Fri Aug 10 19:59:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BCE11E808A for ; Fri, 10 Aug 2012 19:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.694 X-Spam-Level: X-Spam-Status: No, score=-103.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKsxzu18DcbN for ; Fri, 10 Aug 2012 19:59:34 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id F14C511E8087 for ; Fri, 10 Aug 2012 19:59:33 -0700 (PDT) Received: from mail63-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Sat, 11 Aug 2012 02:59:33 +0000 Received: from mail63-co1 (localhost [127.0.0.1]) by mail63-co1-R.bigfish.com (Postfix) with ESMTP id 3C13D740283; Sat, 11 Aug 2012 02:59:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zzbb2dI98dI1432Izz1202hzzz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail63-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail63-co1 (localhost.localdomain [127.0.0.1]) by mail63-co1 (MessageSwitch) id 1344653971199267_16306; Sat, 11 Aug 2012 02:59:31 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.235]) by mail63-co1.bigfish.com (Postfix) with ESMTP id 1DF33BC0049; Sat, 11 Aug 2012 02:59:31 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 11 Aug 2012 02:59:30 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.309.3; Sat, 11 Aug 2012 02:59:29 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Fri, 10 Aug 2012 19:59:29 -0700 From: Dave Thaler To: Brian E Carpenter , Stuart Cheshire Subject: RE: draft-ietf-6man-uri-zoneid-02 Thread-Topic: draft-ietf-6man-uri-zoneid-02 Thread-Index: AQHNdnZ4Pa0foksmsEmR2uKbMBS1xpdTHOuAgADL9KU= Date: Sat, 11 Aug 2012 02:59:28 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B74DCD5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: , <5024B8F9.5090908@gmail.com> In-Reply-To: <5024B8F9.5090908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Bob Hinden , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 02:59:34 -0000 Brian Carpenter writes: > On 09/08/2012 22:31, Stuart Cheshire wrote: > > At the meeting in Vancouver, Dave Thaler made a point that I found > > convincing: > > > > Where is the character set for IPv6 zone IDs specified? > > RFC 4007 doesn't do so, but can be read to imply ASCII. How? RFC 4007 says: > An implementation MAY support other kinds of non-null strings as > . However, the strings must not conflict with the delimiter > character. The precise format and semantics of additional strings is > implementation dependent. So it's completely implementation dependent, the only restriction being that % and null are disallowed. > draft-ietf-6man-uri-zoneid-02 is explicit that it refers to > the URI character set, which is ASCII: > > A SHOULD contain only ASCII characters classified > in RFC 3986 as "unreserved". > > But it allows percent encoding in a URI, which is necessary because of > the SHOULD: > > ZoneID =3D 1*( unreserved / pct-encoded ) ZoneID needs to allow (including via percent-encoding) the same characters as are allowed in in RFC 4007. For example the ']' character would be legal in RFC 4007 but would have to be percent encoded in a URI. > > If we accept > > that future interface names might include non-roman characters, then we > > have to assume that to allow safe unambiguous use in URIs, interface > > names have to undergo escaping. > > If we want to internationalise the ZoneID, that would be a whole > other discussion. It's already allowed by RFC 4007 as far as I know. Stuart's email is an accurate summary of my position. -Dave > > And if the interface name itself is going to be escaped using URI "%xx" > > notation, then why not escape the '%' the same way? > > My impression is that this WG has already objected to that, which is why > we ended up with the current proposal. I leave the next step to the WG Ch= air. > > Brian > > > This argues in support of what Microsoft already did: Encode '%' as "%2= 5". > > > > It's not my favourite outcome, but based on Dave Thaler's comment, it's > > the one that gets my vote. > > > > In the spirit of "be liberal with what you accept" the doc should also > > advocate that URI parsers are forgiving about accepting bare '%' signs > > -- i.e. a '%' not followed by two valid hex characters is left > > untouched. This lets a human user copy-and-paste "fe80::a%en1" from a > > "ping" command and have it work, though the strictly correct form (whic= h > > URI generators should output) remains "fe80::a%25en1". > > > > Stuart Cheshire= From brian.e.carpenter@gmail.com Sat Aug 11 00:40:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF9721F858E for ; Sat, 11 Aug 2012 00:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.482 X-Spam-Level: X-Spam-Status: No, score=-101.482 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bh4ngzcfds9 for ; Sat, 11 Aug 2012 00:40:01 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9A04221F858A for ; Sat, 11 Aug 2012 00:40:00 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so1695851wgb.1 for ; Sat, 11 Aug 2012 00:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/RQFYBwFbXENlzSq3BkoOPh0IIgKjJhiCiyQFFk3D7o=; b=ZytIMFFJ9I0p4TKRBw/R3+0OBrscqQlPzLDAKwVzL58ERbhWQQ3fkZuU9Syrpxf87P T5ors7YHPNSgXclUqK6/UoR81BBAVQH02DIkozVdgLga5IdiMfs8ph3gshtkMbfPeRr7 ffWpipW7NEQpy5Lq2hbELU5vzEW4ETEJjrgQ6NtrmY5PW1WjxgZEJDD9ELzcbKc3srUv uMgeBSgVhQgGm4z1Oo41+Ve4le+V67RqIUU+j/CPniJdcNjdDvoOiCoTOwmQZJq8LKMG BUdbSJ9TSzIkxFbFByUnp8bKEwW6tyJCDXuFdHvbiGkJC+H7nYwzZBJow3IrYDn5UV6H VT+Q== Received: by 10.180.106.137 with SMTP id gu9mr2168824wib.20.1344670799531; Sat, 11 Aug 2012 00:39:59 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-38.as13285.net. [2.102.217.38]) by mx.google.com with ESMTPS id k2sm3469604wiz.7.2012.08.11.00.39.57 (version=SSLv3 cipher=OTHER); Sat, 11 Aug 2012 00:39:58 -0700 (PDT) Message-ID: <50260C5A.7040006@gmail.com> Date: Sat, 11 Aug 2012 08:40:10 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler Subject: Re: draft-ietf-6man-uri-zoneid-02 References: , <5024B8F9.5090908@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B74DCD5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B74DCD5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 07:40:01 -0000 Dave, On 11/08/2012 03:59, Dave Thaler wrote: > Brian Carpenter writes: >> On 09/08/2012 22:31, Stuart Cheshire wrote: >>> At the meeting in Vancouver, Dave Thaler made a point that I found >>> convincing: >>> >>> Where is the character set for IPv6 zone IDs specified? >> RFC 4007 doesn't do so, but can be read to imply ASCII. > > How? RFC 4007 says: >> An implementation MAY support other kinds of non-null strings as >> . However, the strings must not conflict with the delimiter >> character. The precise format and semantics of additional strings is >> implementation dependent. Yes, it says that, but the context to me implies ASCII. We could argue about that for a long time, so let's not bother... > > So it's completely implementation dependent, the only restriction being > that % and null are disallowed. > >> draft-ietf-6man-uri-zoneid-02 is explicit that it refers to >> the URI character set, which is ASCII: >> >> A SHOULD contain only ASCII characters classified >> in RFC 3986 as "unreserved". The draft isn't clear enough (yet) but my idea was that this was part of the update to RFC 4007. >> >> But it allows percent encoding in a URI, which is necessary because of >> the SHOULD: >> >> ZoneID = 1*( unreserved / pct-encoded ) > > ZoneID needs to allow (including via percent-encoding) the same characters > as are allowed in in RFC 4007. For example the ']' > character would be legal in RFC 4007 but would have to be percent > encoded in a URI. Yes > >>> If we accept >>> that future interface names might include non-roman characters, then we >>> have to assume that to allow safe unambiguous use in URIs, interface >>> names have to undergo escaping. >> If we want to internationalise the ZoneID, that would be a whole >> other discussion. > > It's already allowed by RFC 4007 as far as I know. Well, again, it's a matter of interpretation; the question is simply not addressed, which is a defect in the document IMHO. > > Stuart's email is an accurate summary of my position. Yes, but that doesn't help with the %251 problem, which is where we got stuck some months ago and came to the initial decision to add a new delimiter. If people don't want to solve that problem, i.e. accept that %251 in a URI is %1 in ping, and that %251 in ping is %25251 in a URI, then we're done. I'm here as a document editor, looking for guidance. Brian Brian > > -Dave > >>> And if the interface name itself is going to be escaped using URI "%xx" >>> notation, then why not escape the '%' the same way? >> My impression is that this WG has already objected to that, which is why >> we ended up with the current proposal. I leave the next step to the WG Chair. >> >> Brian >> >>> This argues in support of what Microsoft already did: Encode '%' as "%25". >>> >>> It's not my favourite outcome, but based on Dave Thaler's comment, it's >>> the one that gets my vote. >>> >>> In the spirit of "be liberal with what you accept" the doc should also >>> advocate that URI parsers are forgiving about accepting bare '%' signs >>> -- i.e. a '%' not followed by two valid hex characters is left >>> untouched. This lets a human user copy-and-paste "fe80::a%en1" from a >>> "ping" command and have it work, though the strictly correct form (which >>> URI generators should output) remains "fe80::a%25en1". >>> >>> Stuart Cheshire > From ichiroumakino@gmail.com Sat Aug 11 01:33:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004F621F85BB for ; Sat, 11 Aug 2012 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bV6rNngGTvZ for ; Sat, 11 Aug 2012 01:33:55 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD8721F859A for ; Sat, 11 Aug 2012 01:33:54 -0700 (PDT) Received: by eaai11 with SMTP id i11so594603eaa.31 for ; Sat, 11 Aug 2012 01:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=O9OaSxJtFhhHHAIIAFa6hTptKtQhC0vLtWN34bIKx+4=; b=UAZLZDYDAm8GtdvCPGi/QPs8Xgynu+elVDPDA4jR2FPdheQ1oFnQqHdeWrUkZsH06Z pO/bgn/LrZ5oYFk/aVwVlzrQi8KxG9gDH707uhFcu5zZ0L58hytBknbYiSY3eG+Vf3WI N/YZBzBTjxQMsqcWjqb1383Gu5NSTXfOeUoRPnElhA89VtUaY5/v4OxqHmZ+maSEl1Cq gJaH2lsY9dIyKa1FMAOHbRKi+grRSy4GKn6fR3JtZMhtibsL6PR8VUZ/PmUue9ackesC GyTcIUu0RmpcZulPz8DKu/Aofq1Mab+ZERMZnwaiDC70iABjBFhBRpkyMivEFuGGBQTK C0Jg== Received: by 10.14.223.9 with SMTP id u9mr6460951eep.10.1344674034327; Sat, 11 Aug 2012 01:33:54 -0700 (PDT) Received: from dhcp-10-61-99-13.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k41sm3100249eep.13.2012.08.11.01.33.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Aug 2012 01:33:53 -0700 (PDT) Sender: Ole Troan Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_900BF193-EEB3-4800-B0EB-C01A6BD4FD6B"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> Date: Sat, 11 Aug 2012 10:33:51 +0200 Message-Id: <409F28A1-7974-4524-893D-CEF349A96657@employees.org> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1278) Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 08:33:56 -0000 --Apple-Mail=_900BF193-EEB3-4800-B0EB-C01A6BD4FD6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Fred, > Call this "making sure I'm on the same page as anyone else"=85 >=20 > RFC 4941 describes privacy addresses, and RFC 4291 describes an EID = based on a MAC Address. RFC 4862 describes stateless address = autoconfiguration, and uses RFC 4861's duplicate address detection = mechanism. >=20 > My question is: what happens if any of them discovers that it has = created an address that is already in use in the network? >=20 > There would appear to be two options:=20 > (1) "ah, OK, I guess I didn't really want to talk today" > (2) Following RFC 4941, guess again until one creates a unique address >=20 > Is it fair to assume that implementations do DAD and follow (2)? implementations I'm familiar with do 1. it may be a fair assumption that if an address based on the MAC address = is duplicate, the MAC address itself is a duplicate. cheers, Ole= --Apple-Mail=_900BF193-EEB3-4800-B0EB-C01A6BD4FD6B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODExMDgzMzUxWjAjBgkqhkiG9w0BCQQxFgQUPud5vXg9UmKrkbrs PCHvbMUb2fYwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAQAbJYm6O7fBEBbc/UD3G IvaOJSlWs0W4dtbHjSd8koEAXva25uqW1s82hmktz058GFgQp8WWqWPQeHWeAMvFbt+vKFJMgPaR z5GKCnrwpzXxtgfL/KnZN93ow2TEJUO4pGjhMz9XVLvdSDxeoliC1YiLFI31tThXyIJTIr/6xz7T tGafjqgudNG6SZqUxO3k0gcmSO0orkUyIgI3yGLbHNjz9U/q4kY8Ra/Gn6mcs4sOyvHyQ7Z6czTV MjoDaGKElNsf5auiP6ojxnK2R2RdhqBe/GCMJwDasS9EG9+aBbrbyYqpHMMKgMNMfsSEhPM1zd7A 3E3l09hn2EVhWGBAEAAAAAAAAA== --Apple-Mail=_900BF193-EEB3-4800-B0EB-C01A6BD4FD6B-- From bob.hinden@gmail.com Sat Aug 11 08:36:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D5421F8585 for ; Sat, 11 Aug 2012 08:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.396 X-Spam-Level: X-Spam-Status: No, score=-103.396 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlOj4tsn90Wf for ; Sat, 11 Aug 2012 08:36:08 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97CE621F84A1 for ; Sat, 11 Aug 2012 08:36:08 -0700 (PDT) Received: by eaai11 with SMTP id i11so641073eaa.31 for ; Sat, 11 Aug 2012 08:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tFcmLf4FN0KPDnSgcjkQCa3jiD1tyn4M5NNFylTXzuo=; b=n5adpbzLH7C22vfMIqbOhMWAC/7PpJhEWTZ4zQshe5GaGPGO047P5+QEC81A0dMwl4 JgOdgYnRok24YF2h1oQ07RcXCXcJY0faioS87As8zg1Udqj0TuqGnV2rHVf4424q3DtW x6pihwJKCcknYnpIEuZwMGzVQHVujMxNnNF1i3u7eV8N+0qoruIjUX73R/7PcoMx7kA5 E8K9AxfGtl0ZKkoEn22gnoHz9lotGN+YCoumzCg1nLqJyUJf/DGSDbqijW/cvkTy81L+ zFCfkESKPqiHiDva1+5g13ESHCN05iHKJ/UKBKM+i3WA42HfCqp1SxK9+9wPEAMKsF8f c+XQ== Received: by 10.14.220.70 with SMTP id n46mr2838079eep.42.1344699367695; Sat, 11 Aug 2012 08:36:07 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:b53b:99a1:3efd:8902? ([2601:9:4080:10:b53b:99a1:3efd:8902]) by mx.google.com with ESMTPS id u8sm5113134eel.11.2012.08.11.08.36.04 (version=SSLv3 cipher=OTHER); Sat, 11 Aug 2012 08:36:05 -0700 (PDT) Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: <409F28A1-7974-4524-893D-CEF349A96657@employees.org> Date: Sat, 11 Aug 2012 08:36:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1280) Cc: "ipv6@ietf.org 6man" , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:36:09 -0000 Ole, On Aug 11, 2012, at 1:33 AM, Ole Tr=F8an wrote: > Fred, >=20 >> Call this "making sure I'm on the same page as anyone else"=85 >>=20 >> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID = based on a MAC Address. RFC 4862 describes stateless address = autoconfiguration, and uses RFC 4861's duplicate address detection = mechanism. >>=20 >> My question is: what happens if any of them discovers that it has = created an address that is already in use in the network? >>=20 >> There would appear to be two options:=20 >> (1) "ah, OK, I guess I didn't really want to talk today" >> (2) Following RFC 4941, guess again until one creates a unique = address >>=20 >> Is it fair to assume that implementations do DAD and follow (2)? >=20 > implementations I'm familiar with do 1. > it may be a fair assumption that if an address based on the MAC = address is duplicate, the MAC address itself is a duplicate. True, but the odds of this happening are very low. I wonder if we have = any data on DAD detecting duplicate addresses and their cause. For example, has any seen any actual duplicate MAC addresses? It would = be good to collect some data. Bob >=20 > cheers, > = Ole-------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dominik.elsbroek@gmail.com Sat Aug 11 08:45:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8405621F8616 for ; Sat, 11 Aug 2012 08:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mpNfOYbqPbL for ; Sat, 11 Aug 2012 08:45:09 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4C21F8613 for ; Sat, 11 Aug 2012 08:45:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2432276ghb.31 for ; Sat, 11 Aug 2012 08:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qy48W/xDhHAihy+i2yHU4xs2qHelwAcG6zZpSzeWato=; b=WfbZ2M+3TLturRGNbGgTK4QDlgNOVOxFvhqXTPyybAihuX/BEzaAPUz6mvqeqfqGt0 lLWQUf8DizvKWBqEtNWULbxfRxBdUR1pksqoo33fx3NU3gAh9L3i1nVAapvR3eEuDcaL Vb3J46z+ndhWO1ixecfcOX7MWVqapAWPr2wAC30jE3R3z4XU5YWxnXG8cIcTcrKlZGyO mEeUPqP7RaPB8c4At0KHrgpf7u3MVa9ST3KPrGzNfiW/rFJRr6pRu7K8fcSJXOY1tbOQ 1QyE/mbQs8tG6U0JBHLwOFK9Fp3h5MPT+gEPOp5kNH39e+gUReuROf9BRTosnMflnulg 20/g== MIME-Version: 1.0 Received: by 10.42.22.206 with SMTP id p14mr4318220icb.23.1344699908795; Sat, 11 Aug 2012 08:45:08 -0700 (PDT) Received: by 10.50.100.170 with HTTP; Sat, 11 Aug 2012 08:45:08 -0700 (PDT) In-Reply-To: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> Date: Sat, 11 Aug 2012 08:45:08 -0700 Message-ID: Subject: Re: DAD question From: Dominik Elsbroek To: Bob Hinden Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org 6man" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:45:10 -0000 Hi list, i few month ago I played around with dos-new-ip6.c from the IPv6 Attack Toolkit of Marc Heuse (see http://thc.org/thc-ipv6/). The tool answers to any neighbor solicitation with an neighbor advertisement. Debian 6.0.5 sent the neighbor solicitation a few times, always receiving a neighbor advertisement for the desired address. After a few tries Debian just assigned the desired address. This was tested using a OpenVPN network with VMs using VirtualBox. Cheers, Dominik On Sat, Aug 11, 2012 at 8:36 AM, Bob Hinden wrote: > Ole, > > On Aug 11, 2012, at 1:33 AM, Ole Tr=F8an wrote: > >> Fred, >> >>> Call this "making sure I'm on the same page as anyone else"=85 >>> >>> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID bas= ed on a MAC Address. RFC 4862 describes stateless address autoconfiguration= , and uses RFC 4861's duplicate address detection mechanism. >>> >>> My question is: what happens if any of them discovers that it has creat= ed an address that is already in use in the network? >>> >>> There would appear to be two options: >>> (1) "ah, OK, I guess I didn't really want to talk today" >>> (2) Following RFC 4941, guess again until one creates a unique address >>> >>> Is it fair to assume that implementations do DAD and follow (2)? >> >> implementations I'm familiar with do 1. >> it may be a fair assumption that if an address based on the MAC address = is duplicate, the MAC address itself is a duplicate. > > True, but the odds of this happening are very low. I wonder if we have a= ny data on DAD detecting duplicate addresses and their cause. > > For example, has any seen any actual duplicate MAC addresses? It would b= e good to collect some data. > > Bob > >> >> cheers, >> Ole-------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From joelja@bogus.com Sat Aug 11 08:47:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ABC21F8494 for ; Sat, 11 Aug 2012 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN0JHwOWxOK5 for ; Sat, 11 Aug 2012 08:47:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 500C921F8491 for ; Sat, 11 Aug 2012 08:47:41 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7BFlZX2098935 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 11 Aug 2012 15:47:36 GMT (envelope-from joelja@bogus.com) Message-ID: <50267E97.9070906@bogus.com> Date: Sat, 11 Aug 2012 08:47:35 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: Bob Hinden Subject: Re: DAD question References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> In-Reply-To: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 11 Aug 2012 15:47:36 +0000 (UTC) Cc: "ipv6@ietf.org 6man" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:47:42 -0000 On 8/11/12 8:36 AM, Bob Hinden wrote: > Ole, > > On Aug 11, 2012, at 1:33 AM, Ole Trøan wrote: > >> Fred, >> >>> Call this "making sure I'm on the same page as anyone else"… >>> >>> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID based on a MAC Address. RFC 4862 describes stateless address autoconfiguration, and uses RFC 4861's duplicate address detection mechanism. >>> >>> My question is: what happens if any of them discovers that it has created an address that is already in use in the network? >>> >>> There would appear to be two options: >>> (1) "ah, OK, I guess I didn't really want to talk today" >>> (2) Following RFC 4941, guess again until one creates a unique address >>> >>> Is it fair to assume that implementations do DAD and follow (2)? >> implementations I'm familiar with do 1. >> it may be a fair assumption that if an address based on the MAC address is duplicate, the MAC address itself is a duplicate. > True, but the odds of this happening are very low. I wonder if we have any data on DAD detecting duplicate addresses and their cause. > > For example, has any seen any actual duplicate MAC addresses? It would be good to collect some data. Most sun machines that I recall had the same mac address on all interfaces. Duplicate macs are generally in my experience the product of deliberate configuration, cloning virtual machines or similar activity. > Bob > >> cheers, >> Ole-------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From sthaug@nethelp.no Sat Aug 11 09:01:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3971A21F850D for ; Sat, 11 Aug 2012 09:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.39 X-Spam-Level: X-Spam-Status: No, score=-5.39 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29m6Vqk4BbF9 for ; Sat, 11 Aug 2012 09:01:07 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 9621E21F84D8 for ; Sat, 11 Aug 2012 09:01:06 -0700 (PDT) Received: (qmail 72929 invoked from network); 11 Aug 2012 16:01:04 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Aug 2012 16:01:04 -0000 Date: Sat, 11 Aug 2012 18:01:04 +0200 (CEST) Message-Id: <20120811.180104.41668882.sthaug@nethelp.no> To: bob.hinden@gmail.com Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:01:08 -0000 > > it may be a fair assumption that if an address based on the MAC address is duplicate, the MAC address itself is a duplicate. > > True, but the odds of this happening are very low. I wonder if we have any data on DAD detecting duplicate addresses and their cause. You may need to qualify "very low". > For example, has any seen any actual duplicate MAC addresses? It would be good to collect some data. Duplicate MAC addresses are regularly seen in the wild. As an example, from a nearby DHCP server, I have the following duplicates from a total of 65499 MAC addresses: 5 00:90:4c:91:00:01; 3 00:40:10:20:00:02; 3 00:00:00:00:00:00; 2 bc:b1:f3:61:28:e3; 2 98:0c:82:84:ef:83; 2 34:21:09:03:76:f9; 2 00:1f:1f:8c:d4:d5; 2 00:1f:1f:8c:d4:cd; 2 00:1d:73:11:11:13; 2 00:11:22:33:44:56; So from this sample a total of 10 MAC addresses occur more than once (different customers, different locations). I make no claims about these numbers being representative. My main point is that duplicates *occur*, for several different reasons, e.g. - Manufacturing mistakes - Software bugs - MAC address explicitly set Steinar Haug, Nethelp consulting, sthaug@nethelp.no From swmike@swm.pp.se Sat Aug 11 09:57:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29EC21F846D for ; Sat, 11 Aug 2012 09:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-79ncyOHv0I for ; Sat, 11 Aug 2012 09:57:55 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69321F846B for ; Sat, 11 Aug 2012 09:57:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1C8FC9C; Sat, 11 Aug 2012 18:57:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 131E99A; Sat, 11 Aug 2012 18:57:53 +0200 (CEST) Date: Sat, 11 Aug 2012 18:57:53 +0200 (CEST) From: Mikael Abrahamsson To: sthaug@nethelp.no Subject: Re: DAD question In-Reply-To: <20120811.180104.41668882.sthaug@nethelp.no> Message-ID: References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipv6@ietf.org, bob.hinden@gmail.com, fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:57:55 -0000 On Sat, 11 Aug 2012, sthaug@nethelp.no wrote: > So from this sample a total of 10 MAC addresses occur more than once > (different customers, different locations). I concur. Back 5-8 years ago, we had a few percent of our household customers use the same MAC address, namely the one D-link assigned by default to their NAT boxes and then added an option to "clone" an inside PC address if one wanted to change the WAN facing address. MAC addresses being non-unique is happening a lot more commonly than it should, and needs to be taken in account. -- Mikael Abrahamsson email: swmike@swm.pp.se From dthaler@microsoft.com Sat Aug 11 10:14:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630B121F85DD for ; Sat, 11 Aug 2012 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.193 X-Spam-Level: X-Spam-Status: No, score=-105.193 tagged_above=-999 required=5 tests=[AWL=1.406, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7asy1U2DobY for ; Sat, 11 Aug 2012 10:14:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98121F85D6 for ; Sat, 11 Aug 2012 10:14:24 -0700 (PDT) Received: from mail115-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Sat, 11 Aug 2012 17:14:23 +0000 Received: from mail115-tx2 (localhost [127.0.0.1]) by mail115-tx2-R.bigfish.com (Postfix) with ESMTP id 29E8F380207; Sat, 11 Aug 2012 17:14:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI98dI9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail115-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail115-tx2 (localhost.localdomain [127.0.0.1]) by mail115-tx2 (MessageSwitch) id 1344705260951397_6775; Sat, 11 Aug 2012 17:14:20 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.249]) by mail115-tx2.bigfish.com (Postfix) with ESMTP id DBAE8200133; Sat, 11 Aug 2012 17:14:20 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 11 Aug 2012 17:14:20 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Sat, 11 Aug 2012 17:14:19 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Sat, 11 Aug 2012 10:14:19 -0700 From: Dave Thaler To: Brian E Carpenter Subject: RE: draft-ietf-6man-uri-zoneid-02 Thread-Topic: draft-ietf-6man-uri-zoneid-02 Thread-Index: AQHNdnZ4Pa0foksmsEmR2uKbMBS1xpdTHOuAgADL9KWAAMieAIAAKipg Date: Sat, 11 Aug 2012 17:14:19 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B74E6D4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: , <5024B8F9.5090908@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B74DCD5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <50260C5A.7040006@gmail.com> In-Reply-To: <50260C5A.7040006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org" , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:14:25 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Saturday, August 11, 2012 3:40 AM > To: Dave Thaler > Cc: Bob Hinden; ipv6@ietf.org > Subject: Re: draft-ietf-6man-uri-zoneid-02 >=20 > Dave, >=20 > On 11/08/2012 03:59, Dave Thaler wrote: > > Brian Carpenter writes: > >> On 09/08/2012 22:31, Stuart Cheshire wrote: > >>> At the meeting in Vancouver, Dave Thaler made a point that I found > >>> convincing: > >>> > >>> Where is the character set for IPv6 zone IDs specified? > >> RFC 4007 doesn't do so, but can be read to imply ASCII. > > > > How? RFC 4007 says: > >> An implementation MAY support other kinds of non-null strings as > >> . However, the strings must not conflict with the delimiter > >> character. The precise format and semantics of additional strings is > >> implementation dependent. >=20 > Yes, it says that, but the context to me implies ASCII. We could argue ab= out > that for a long time, so let's not bother... >=20 > > So it's completely implementation dependent, the only restriction > > being that % and null are disallowed. > > > >> draft-ietf-6man-uri-zoneid-02 is explicit that it refers to the URI > >> character set, which is ASCII: > >> > >> A SHOULD contain only ASCII characters classified > >> in RFC 3986 as "unreserved". >=20 > The draft isn't clear enough (yet) but my idea was that this was part of = the > update to RFC 4007. During the Vancouver meeting, the chairs called the question of whether to Update 4007 or not. The clear sense of the room was not to do so. Assuming that consensus continues to hold on the list, I believe this means the sentence you quote needs to be removed, and we cannot place any restrictions on zone_id that aren't in 4007. -Dave > >> But it allows percent encoding in a URI, which is necessary because > >> of the SHOULD: > >> > >> ZoneID =3D 1*( unreserved / pct-encoded ) > > > > ZoneID needs to allow (including via percent-encoding) the same > > characters as are allowed in in RFC 4007. For example the ']= ' > > character would be legal in RFC 4007 but would have to be percent > > encoded in a URI. >=20 > Yes >=20 > > > >>> If we accept > >>> that future interface names might include non-roman characters, then > >>> we have to assume that to allow safe unambiguous use in URIs, > >>> interface names have to undergo escaping. > >> If we want to internationalise the ZoneID, that would be a whole > >> other discussion. > > > > It's already allowed by RFC 4007 as far as I know. >=20 > Well, again, it's a matter of interpretation; the question is simply not > addressed, which is a defect in the document IMHO. >=20 > > > > Stuart's email is an accurate summary of my position. >=20 > Yes, but that doesn't help with the %251 problem, which is where we got > stuck some months ago and came to the initial decision to add a new > delimiter. If people don't want to solve that problem, i.e. accept that %= 251 in > a URI is %1 in ping, and that %251 in ping is %25251 in a URI, then we're= done. >=20 > I'm here as a document editor, looking for guidance. >=20 > Brian >=20 > Brian >=20 > > > > -Dave > > > >>> And if the interface name itself is going to be escaped using URI "%x= x" > >>> notation, then why not escape the '%' the same way? > >> My impression is that this WG has already objected to that, which is > >> why we ended up with the current proposal. I leave the next step to th= e > WG Chair. > >> > >> Brian > >> > >>> This argues in support of what Microsoft already did: Encode '%' as > "%25". > >>> > >>> It's not my favourite outcome, but based on Dave Thaler's comment, > >>> it's the one that gets my vote. > >>> > >>> In the spirit of "be liberal with what you accept" the doc should > >>> also advocate that URI parsers are forgiving about accepting bare > >>> '%' signs > >>> -- i.e. a '%' not followed by two valid hex characters is left > >>> untouched. This lets a human user copy-and-paste "fe80::a%en1" from > >>> a "ping" command and have it work, though the strictly correct form > >>> (which URI generators should output) remains "fe80::a%25en1". > >>> > >>> Stuart Cheshire > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Sat Aug 11 10:18:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7630021F84EC for ; Sat, 11 Aug 2012 10:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXYvX2GRmCVK for ; Sat, 11 Aug 2012 10:18:06 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E992021F8484 for ; Sat, 11 Aug 2012 10:17:59 -0700 (PDT) Received: from [186.134.19.36] (helo=[192.168.123.104]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T0FJs-0002Gg-Mi; Sat, 11 Aug 2012 19:17:54 +0200 Message-ID: <50269379.3010100@si6networks.com> Date: Sat, 11 Aug 2012 14:16:41 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Bob Hinden Subject: Re: DAD question References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> In-Reply-To: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org 6man" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:18:06 -0000 Hi, Bob, On 08/11/2012 12:36 PM, Bob Hinden wrote: >>> There would appear to be two options: >>> (1) "ah, OK, I guess I didn't really want to talk today" >>> (2) Following RFC 4941, guess again until one creates a unique address >>> >>> Is it fair to assume that implementations do DAD and follow (2)? >> >> implementations I'm familiar with do 1. >> it may be a fair assumption that if an address based on the MAC address is duplicate, the MAC address itself is a duplicate. > > True, but the odds of this happening are very low. I wonder if we have any data on DAD detecting duplicate addresses and their cause. Virtual machines? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Sat Aug 11 11:57:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782F321F84EF for ; Sat, 11 Aug 2012 11:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.164 X-Spam-Level: X-Spam-Status: No, score=-110.164 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQIc3pLuGqfW for ; Sat, 11 Aug 2012 11:57:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 95AD121F84E7 for ; Sat, 11 Aug 2012 11:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=988; q=dns/txt; s=iport; t=1344711461; x=1345921061; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YNFOAZEd1H642w1FvyM4qMmtv+buGIzMsmym2jzN77E=; b=TBkH+/VDYnQe1JwuECShSNCPPMmYr0BFhDTPTciYUoqPlxwrrKDRaNLo 2hJSbGSO11M7KVv1z+XvKrDr0VdaXQDgs1gyO9fg8SwqIr0YZY7Mlw2Da iV0qLzEDkDTo5iwr/B25+PnBVpXQZz7cZ/+MMVx9esSm6N1umDWz6xS1K Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPupJlCtJV2Y/2dsb2JhbABEuXqBB4IgAQEBAwESAWYFCwIBCEYyJQIEDieHZQaYZJ9lixKFUWADlUuOKoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,751,1336348800"; d="scan'208";a="110646944" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 11 Aug 2012 18:57:41 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7BIvfX7013501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Aug 2012 18:57:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Sat, 11 Aug 2012 13:57:41 -0500 From: "Fred Baker (fred)" To: =?Windows-1252?Q?Ole_Tr=F8an?= Subject: Re: DAD question Thread-Topic: DAD question Thread-Index: AQHNd0XlCeAhXXPBcEK2v5tAiE4SZZdUnVeAgACuSoA= Date: Sat, 11 Aug 2012 18:57:40 +0000 Message-ID: References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> In-Reply-To: <409F28A1-7974-4524-893D-CEF349A96657@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19104.001 x-tm-as-result: No--34.728800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <93222E3C199EF5448C6C2BEAE9CC75F7@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 18:57:42 -0000 On Aug 11, 2012, at 1:33 AM, Ole Tr=F8an wrote: > Fred, >=20 >> Call this "making sure I'm on the same page as anyone else"=85 >>=20 >> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID base= d on a MAC Address. RFC 4862 describes stateless address autoconfiguration,= and uses RFC 4861's duplicate address detection mechanism. >>=20 >> My question is: what happens if any of them discovers that it has create= d an address that is already in use in the network? >>=20 >> There would appear to be two options:=20 >> (1) "ah, OK, I guess I didn't really want to talk today" >> (2) Following RFC 4941, guess again until one creates a unique address >>=20 >> Is it fair to assume that implementations do DAD and follow (2)? >=20 > implementations I'm familiar with do 1. > it may be a fair assumption that if an address based on the MAC address i= s duplicate, the MAC address itself is a duplicate. And that relates to privacy addresses how?= From ichiroumakino@gmail.com Sat Aug 11 12:04:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDEC21F862A for ; Sat, 11 Aug 2012 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcPgyEZXcWbQ for ; Sat, 11 Aug 2012 12:04:14 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0106521F8620 for ; Sat, 11 Aug 2012 12:04:13 -0700 (PDT) Received: by eekb45 with SMTP id b45so660593eek.31 for ; Sat, 11 Aug 2012 12:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=dJxVfrXsgCDE8f3Hc3uAk5qww46JFIVDi4JP8kY7/gc=; b=iBG6bbwlzZtVoDAybIQEBxTR+jXjKajeJZNKtEMBxGnz27pZcevpcLZ3lxuWNIHGWL PEdLGa5yw4nVR72CVdfoSFXBMlKHoK4eiN42PCDhuX1+BcnqSQRNHbpKzwFRD1/HaUlU cmQ5lKhOn94WPFfF6KWthn1n7RJzY2V+FAbVr8h7pt8JhZUk61bPJkqigatPX6pPZYWX +lEQiHLvlouqF/HbGrjiPJU9ioF/DgI+NCO05XU58PsOm1XB7db3p94YT6NB7vH8KWCL +/FqArOmyJYTQ1y+a4pkc+f9K+pqQHP651JHks5Jw8ZHz6vHjqjRZ9kLdVPz0Kon+g9h j2OA== Received: by 10.14.207.9 with SMTP id m9mr7968875eeo.5.1344711853147; Sat, 11 Aug 2012 12:04:13 -0700 (PDT) Received: from ?IPv6:2a02:fe0:cf15:30:94f:939c:b36b:aea3? ([2a02:fe0:cf15:30:94f:939c:b36b:aea3]) by mx.google.com with ESMTPS id 45sm6106635eeb.8.2012.08.11.12.04.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Aug 2012 12:04:11 -0700 (PDT) Sender: Ole Troan Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_E424D2D9-BED3-436D-A8C4-379C2DD7777A"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Sat, 11 Aug 2012 21:04:10 +0200 Message-Id: <91A5DDF6-B956-492F-A430-E1A3DF34B67D@employees.org> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1278) Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 19:04:15 -0000 --Apple-Mail=_E424D2D9-BED3-436D-A8C4-379C2DD7777A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >>> Call this "making sure I'm on the same page as anyone else"=85 >>>=20 >>> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID = based on a MAC Address. RFC 4862 describes stateless address = autoconfiguration, and uses RFC 4861's duplicate address detection = mechanism. >>>=20 >>> My question is: what happens if any of them discovers that it has = created an address that is already in use in the network? >>>=20 >>> There would appear to be two options:=20 >>> (1) "ah, OK, I guess I didn't really want to talk today" >>> (2) Following RFC 4941, guess again until one creates a unique = address >>>=20 >>> Is it fair to assume that implementations do DAD and follow (2)? >>=20 >> implementations I'm familiar with do 1. >> it may be a fair assumption that if an address based on the MAC = address is duplicate, the MAC address itself is a duplicate. >=20 > And that relates to privacy addresses how? it doesn't. is your question how DAD is done for privacy addresses? then section 3.3 of RFC4941 is quite clear on that. cheers, Ole= --Apple-Mail=_E424D2D9-BED3-436D-A8C4-379C2DD7777A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODExMTkwNDExWjAjBgkqhkiG9w0BCQQxFgQUZQKqZSNKJCqanDXF KSoiS+iV5BswggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAgL3ll6a9tCnvrcBnHVdP ArGLj2AxJmrAYL6QziEqMBsainXhtE7ets5zB1L7K6HhdUgVTGnEi2gmaDqL9aE922Ro79GApq0X toDwRbhnEpHH/d0paRSo7d+vSJTlYqtpI1EUxGRXTpC3HyfuCR8/Bp20N9sZeAXr1Vc0qlQdd+Do t4EZxdcKDl+L5ZPX2Z9n6ijUWbd2BzEDI9kldLnhtPfGuAmxsbu+MrOm8OInXKAc7nU6TwUY1DZb tr40ZQ+jnbgeRShX/4+T3DdhJpCQtfR/dJCC0JdfVYfkMm0czDbx1LrjjzhiA8A6Pwflp0zqZK5D Lhgao/vyq5Zo4S1FtAAAAAAAAA== --Apple-Mail=_E424D2D9-BED3-436D-A8C4-379C2DD7777A-- From fred@cisco.com Sat Aug 11 13:11:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDE021F856D for ; Sat, 11 Aug 2012 13:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.167 X-Spam-Level: X-Spam-Status: No, score=-110.167 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzVl5Gzw-4TQ for ; Sat, 11 Aug 2012 13:11:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BE9E721F850B for ; Sat, 11 Aug 2012 13:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1396; q=dns/txt; s=iport; t=1344715867; x=1345925467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zVuWTzU/OSOk5k1EwwI5d37n52uu3almEV82rLCUCJ0=; b=hmg+DASJ3gPiBm3Txm/WHbLtkXDDCk/PU+bevQ+SlMEeWXIP9rsvz7pl D+LyNRJVUgn2hCE+h9ES9kwBIYHYBFcAR2rr628qRBJrmsU3RfosmhXt8 j0neUk+NIpSq20YKmDK0Z//A/LLsOfmO0wxkNt3m3uhbrHgv9KRFmHAUw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACG7JlCtJV2Y/2dsb2JhbABFuXuBB4IgAQEBAwESAWYFCwIBCEYyJQIEDieHZQaYbZ9eixKFUWADlUuOKoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,752,1336348800"; d="scan'208";a="110443241" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 11 Aug 2012 20:11:07 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7BKB7KK014821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Aug 2012 20:11:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sat, 11 Aug 2012 15:11:07 -0500 From: "Fred Baker (fred)" To: =?Windows-1252?Q?Ole_Tr=F8an?= Subject: Re: DAD question Thread-Topic: DAD question Thread-Index: AQHNd0XlCeAhXXPBcEK2v5tAiE4SZZdUnVeAgACuSoCAAAHSAIAAErEA Date: Sat, 11 Aug 2012 20:11:06 +0000 Message-ID: <9B9125B1-E4F1-47DC-8E06-B0A7E3F1A73C@cisco.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <91A5DDF6-B956-492F-A430-E1A3DF34B67D@employees.org> In-Reply-To: <91A5DDF6-B956-492F-A430-E1A3DF34B67D@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19102.004 x-tm-as-result: No--38.622100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <54E8EBC60EBE084AAF3FFE2717038823@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 20:11:08 -0000 On Aug 11, 2012, at 12:04 PM, Ole Tr=F8an wrote: >>>> Call this "making sure I'm on the same page as anyone else"=85 >>>>=20 >>>> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID ba= sed on a MAC Address. RFC 4862 describes stateless address autoconfiguratio= n, and uses RFC 4861's duplicate address detection mechanism. >>>>=20 >>>> My question is: what happens if any of them discovers that it has crea= ted an address that is already in use in the network? >>>>=20 >>>> There would appear to be two options:=20 >>>> (1) "ah, OK, I guess I didn't really want to talk today" >>>> (2) Following RFC 4941, guess again until one creates a unique address >>>>=20 >>>> Is it fair to assume that implementations do DAD and follow (2)? >>>=20 >>> implementations I'm familiar with do 1. >>> it may be a fair assumption that if an address based on the MAC address= is duplicate, the MAC address itself is a duplicate. >>=20 >> And that relates to privacy addresses how? >=20 > it doesn't. is your question how DAD is done for privacy addresses? My question is for all addresses. I'm getting responses for MAC addresses. > then section 3.3 of RFC4941 is quite clear on that. >=20 > cheers, > Ole ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From kauer@biplane.com.au Sat Aug 11 14:39:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC25B11E8097 for ; Sat, 11 Aug 2012 14:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOIPve4hMhYw for ; Sat, 11 Aug 2012 14:39:12 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 4682611E8087 for ; Sat, 11 Aug 2012 14:39:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBANrPJlCWZX+7/2dsb2JhbAANOIYBtyEBAQEEI2YLGAICJgICVxmtJ26SPYEhjQaCCoESA5Fpjm+HdA Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 12 Aug 2012 07:09:07 +0930 Message-ID: <1344721144.6453.29.camel@karl> Subject: Re: DAD question From: Karl Auer To: ipv6@ietf.org Date: Sun, 12 Aug 2012 07:39:04 +1000 In-Reply-To: <20120811.180104.41668882.sthaug@nethelp.no> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 21:39:13 -0000 On Sat, 2012-08-11 at 18:01 +0200, sthaug@nethelp.no wrote: > Duplicate MAC addresses are regularly seen in the wild. It's important to remember that DAD is link local. It is only checking whether the same address occurs on the local link. Duplicate MAC addresses are not actually a problem as long as the duplicates are not on the same link. If the duplicates ARE on the same link, then you have a real problem at layer 2 anyway. The same link local address, based on a MAC, is also a real problem if it's duplicated, for much the same reason. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From sthaug@nethelp.no Sat Aug 11 14:48:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701BE11E809A for ; Sat, 11 Aug 2012 14:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+afyNe5Wvbu for ; Sat, 11 Aug 2012 14:48:50 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 7F22C11E8087 for ; Sat, 11 Aug 2012 14:48:49 -0700 (PDT) Received: (qmail 97321 invoked from network); 11 Aug 2012 21:48:46 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Aug 2012 21:48:46 -0000 Date: Sat, 11 Aug 2012 23:48:46 +0200 (CEST) Message-Id: <20120811.234846.71124335.sthaug@nethelp.no> To: kauer@biplane.com.au Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: <1344721144.6453.29.camel@karl> References: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> <1344721144.6453.29.camel@karl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 21:48:50 -0000 > > Duplicate MAC addresses are regularly seen in the wild. > > It's important to remember that DAD is link local. It is only checking > whether the same address occurs on the local link. Duplicate MAC > addresses are not actually a problem as long as the duplicates are not > on the same link. If the duplicates ARE on the same link, then you have > a real problem at layer 2 anyway. The same link local address, based on > a MAC, is also a real problem if it's duplicated, for much the same > reason. We use the 1:1 VLAN model for our customers, so in that sense I agree with you - these duplicates would not be a problem in our case. If we had used the N:1 VLAN model instead, it could be a very real problem. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From fgont@si6networks.com Sat Aug 11 14:53:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15E411E80A3 for ; Sat, 11 Aug 2012 14:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7iBfd+oUEAJ for ; Sat, 11 Aug 2012 14:53:20 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6E111E8087 for ; Sat, 11 Aug 2012 14:53:20 -0700 (PDT) Received: from [186.134.19.36] (helo=[192.168.123.104]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T0JcK-00014F-B1; Sat, 11 Aug 2012 23:53:13 +0200 Message-ID: <5026D409.5010001@si6networks.com> Date: Sat, 11 Aug 2012 18:52:09 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Karl Auer Subject: Re: DAD question References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> <1344721144.6453.29.camel@karl> In-Reply-To: <1344721144.6453.29.camel@karl> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 21:53:21 -0000 On 08/11/2012 06:39 PM, Karl Auer wrote: > If the duplicates ARE on the same link, then you have > a real problem at layer 2 anyway. It sucks -- e.g., performance-wise. However, if the layer above 2 employs addressing (e.g. IPv4 and IPv6), things should still work even in the presence of *this* problem. Traditional SLAAC addresses deriving the IPv6 address from the (now non-unique) MAC address introduces a different problem. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bob.hinden@gmail.com Sat Aug 11 15:17:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F07A21F84D8 for ; Sat, 11 Aug 2012 15:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEGc7y3CHcCd for ; Sat, 11 Aug 2012 15:17:20 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72BBA21F84D6 for ; Sat, 11 Aug 2012 15:17:20 -0700 (PDT) Received: by eaai11 with SMTP id i11so677338eaa.31 for ; Sat, 11 Aug 2012 15:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yrokgH9uAuiuX/5PGKqpF7DhYaW4pmraKqdnTq/74Q0=; b=xDN3UCVC+GeykMWIHynE/MNM5qqd2nXweXJWBv6foSHLcjPDnRV35uB5iA2RF3Kc+U fxCC2ghpmh8G957L4UKo5W1cWzI/KUH3CthN2qxziCWdLIQVW5NhNopRYBZ/7g3i7++l c39UCd6LTbvE6sQISuxd3Yuk4HtPrEh/M/BBqU/7xoqTJIRTTSVTOPdYFzMtz6cAhtke quo2MlOyt/6RA2u3pqPCUdp+9Bnb3t9H+pR6CunTdl4TbLDZXYQaTCTY1JwR6vPWPzgG blgk+C3MAftORQ7Qg2zXjWH6sv+zoupdJS7Pyn+7WuLMNDyx/+aytWMXi2S6DJKVhxyF 5bkQ== Received: by 10.14.204.72 with SMTP id g48mr8273828eeo.45.1344723439574; Sat, 11 Aug 2012 15:17:19 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:bc1a:ad21:cee:c8a9? ([2601:9:4080:10:bc1a:ad21:cee:c8a9]) by mx.google.com with ESMTPS id h42sm7021947eem.5.2012.08.11.15.17.15 (version=SSLv3 cipher=OTHER); Sat, 11 Aug 2012 15:17:17 -0700 (PDT) Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <20120811.180104.41668882.sthaug@nethelp.no> Date: Sat, 11 Aug 2012 15:17:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1280) Cc: ipv6@ietf.org, Bob Hinden , fred@cisco.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 22:17:21 -0000 Steinar, On Aug 11, 2012, at 9:01 AM, sthaug@nethelp.no wrote: >>> it may be a fair assumption that if an address based on the MAC = address is duplicate, the MAC address itself is a duplicate. >>=20 >> True, but the odds of this happening are very low. I wonder if we = have any data on DAD detecting duplicate addresses and their cause. >=20 > You may need to qualify "very low". >=20 >> For example, has any seen any actual duplicate MAC addresses? It = would be good to collect some data. >=20 > Duplicate MAC addresses are regularly seen in the wild. As an example, > from a nearby DHCP server, I have the following duplicates from a = total > of 65499 MAC addresses: >=20 > 5 00:90:4c:91:00:01; > 3 00:40:10:20:00:02; > 3 00:00:00:00:00:00; > 2 bc:b1:f3:61:28:e3; > 2 98:0c:82:84:ef:83; > 2 34:21:09:03:76:f9; > 2 00:1f:1f:8c:d4:d5; > 2 00:1f:1f:8c:d4:cd; > 2 00:1d:73:11:11:13; > 2 00:11:22:33:44:56; >=20 > So from this sample a total of 10 MAC addresses occur more than once > (different customers, different locations). Interesting. Are these different machines/interfaces with the same Mac = addresses, or the same machine connecting via some other path or = location. My question was about machines/interfaces. That is, are we seeing = manufacturing mistakes, etc.? Thanks, Bob >=20 > I make no claims about these numbers being representative. My main=20 > point is that duplicates *occur*, for several different reasons, e.g. >=20 > - Manufacturing mistakes > - Software bugs > - MAC address explicitly set >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no From bob.hinden@gmail.com Sat Aug 11 15:18:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A4021F84EF for ; Sat, 11 Aug 2012 15:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts0ub45Ugdgy for ; Sat, 11 Aug 2012 15:18:11 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7AB21F84D6 for ; Sat, 11 Aug 2012 15:18:11 -0700 (PDT) Received: by eaai11 with SMTP id i11so677378eaa.31 for ; Sat, 11 Aug 2012 15:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vKI5cJ3LlPTddLD2xzFCpq/N+TSPp97jDXNo0BWo7wU=; b=qqB2lrpM/TO7geCfL3bwOKuenSeMk0xLBUORov9xUUff2PcnpsPLKGSO0+fzlEYrFZ OEnRY/qqWZYuDSENwER5/CjPh6sWA8ywCIqISYNmiSd/D7PpiVZpwB0mL5oafHxg7RRW NxFQBXa5pVUeoW5vRQ8kRDN1XdGtbQj+YGzpwWQrBwgRnSqdEZgmP70xdwZyLHaFKi2d J3v7MJw3AuwzZJaWiZDv6+9LfAM6xqB7TkPvN/+/c12j/ZFW+XoeM3J/4exOr2DNXapX tYBKpaU9hl/G3LylObtDeIjv9lMd8Dn7gdlfxUGFPEsVMJtUbzRRwYeg3UaEvxht4ARF FpKQ== Received: by 10.14.175.8 with SMTP id y8mr4109675eel.8.1344723490532; Sat, 11 Aug 2012 15:18:10 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:bc1a:ad21:cee:c8a9? ([2601:9:4080:10:bc1a:ad21:cee:c8a9]) by mx.google.com with ESMTPS id h42sm7021947eem.5.2012.08.11.15.18.04 (version=SSLv3 cipher=OTHER); Sat, 11 Aug 2012 15:18:08 -0700 (PDT) Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: <50269379.3010100@si6networks.com> Date: Sat, 11 Aug 2012 15:18:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <50269379.3010100@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1280) Cc: "ipv6@ietf.org 6man" , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 22:18:12 -0000 On Aug 11, 2012, at 10:16 AM, Fernando Gont wrote: > Hi, Bob, >=20 > On 08/11/2012 12:36 PM, Bob Hinden wrote: >>>> There would appear to be two options:=20 >>>> (1) "ah, OK, I guess I didn't really want to talk today" >>>> (2) Following RFC 4941, guess again until one creates a unique = address >>>>=20 >>>> Is it fair to assume that implementations do DAD and follow (2)? >>>=20 >>> implementations I'm familiar with do 1. >>> it may be a fair assumption that if an address based on the MAC = address is duplicate, the MAC address itself is a duplicate. >>=20 >> True, but the odds of this happening are very low. I wonder if we = have any data on DAD detecting duplicate addresses and their cause. >=20 > Virtual machines? Good point. =20 Thanks, Bob >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 From bob.hinden@gmail.com Sat Aug 11 15:20:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA921F84D2 for ; Sat, 11 Aug 2012 15:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.686 X-Spam-Level: X-Spam-Status: No, score=-103.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8cRQxD6ImW8 for ; Sat, 11 Aug 2012 15:20:38 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C724F21F8443 for ; Sat, 11 Aug 2012 15:20:37 -0700 (PDT) Received: by eekb45 with SMTP id b45so677481eek.31 for ; Sat, 11 Aug 2012 15:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MV9tNCD+KTTq0SY9u2qzqKsYRXVNR2NS+9/I2Sxj9K8=; b=Uobf/VrmCI/Jp+YL8QMtM2kLyRsdZJByCSnZsVasJvee7tDIGLDv4Ohcqt9V/8txEq BQSbqnn2DTfS9mCciOMw1RaUBi6lsSA2bGJds/+/Nh3PH5jORMdfOXQFoI49a96f5ngc YMlrez/SEmczsWhody07+RcFAsQWD1h77rpN9A/qFWcWLH4SldeRfc/sDG1ij6GCQfVL /yIRPFkNb6LdLXq8Vv64sVsokjPk2ADVaJyR4GoXVKxDxmHzSCw36knKH8FpJOdi6l6d DL/ih+y9OhQgsAQaL1RVS01bBuJ1E4YbmZUWDvMn794ThxD+duIKsp38uWXyw1FADRmc TgUw== Received: by 10.14.223.9 with SMTP id u9mr8364060eep.10.1344723635910; Sat, 11 Aug 2012 15:20:35 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:bc1a:ad21:cee:c8a9? ([2601:9:4080:10:bc1a:ad21:cee:c8a9]) by mx.google.com with ESMTPS id 9sm7016435eei.12.2012.08.11.15.20.33 (version=SSLv3 cipher=OTHER); Sat, 11 Aug 2012 15:20:35 -0700 (PDT) Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: <50267E97.9070906@bogus.com> Date: Sat, 11 Aug 2012 15:20:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36044B22-E9CF-4707-B060-DAA48D2A4FEA@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <50267E97.9070906@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1280) Cc: "ipv6@ietf.org 6man" , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 22:20:38 -0000 Joel, >>>=20 >>>=20 >> True, but the odds of this happening are very low. I wonder if we = have any data on DAD detecting duplicate addresses and their cause. >>=20 >> For example, has any seen any actual duplicate MAC addresses? It = would be good to collect some data. > Most sun machines that I recall had the same mac address on all = interfaces. Right, but that would cause DAD to trigger unless the interfaces were = connected to the same link. I would think this is an issue for servers. >=20 > Duplicate macs are generally in my experience the product of = deliberate configuration, cloning virtual machines or similar activity. That makes sense. Thanks, Bob >> Bob >>=20 >>> cheers, >>> = Ole-------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 From brian.e.carpenter@gmail.com Sun Aug 12 00:19:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2A711E80A2 for ; Sun, 12 Aug 2012 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.494 X-Spam-Level: X-Spam-Status: No, score=-101.494 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in1DvvmCrSFc for ; Sun, 12 Aug 2012 00:19:57 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3457A11E809B for ; Sun, 12 Aug 2012 00:19:57 -0700 (PDT) Received: by wicr5 with SMTP id r5so1251686wic.13 for ; Sun, 12 Aug 2012 00:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7//uOIztfU7a9O8D0AMLIG3SwPtkJue+bQcG6yZGXlI=; b=rPWTIgI4Y67iJ7LetFXNCItrmfo2Wqli+Og70zbVns4NDQDizxtrrhWsoThDFYEY/r VNNOMQlHu8iOQJWCHicGE5bh/hiCbPm9mcxhzx4b4+s4lwVxYh0RaNJ5SfTjG8u+u5fL ntr0nkMxQ7lZbS+DRqx3Gu6rnFBVkdYwh5GJ0qw5EYEef3CWM8Hqi38T2aLQQ0VK4wFN XwzMp0X8oxWoPgnYaqCe1CNvAY14ATqVZ3NFHKZBNihgMYdLvdPY5puNFVCarC7C2xVL YlVSBgo2kK4/7Rg4j7BBCtnD/dc/q4xjmJHh6TZlZpiVipETc50O03LoVYIUtX/rdOZ8 ZXVw== Received: by 10.216.132.25 with SMTP id n25mr4029533wei.25.1344755994133; Sun, 12 Aug 2012 00:19:54 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-150.as13285.net. [2.102.217.150]) by mx.google.com with ESMTPS id cu1sm8561011wib.6.2012.08.12.00.19.52 (version=SSLv3 cipher=OTHER); Sun, 12 Aug 2012 00:19:53 -0700 (PDT) Message-ID: <50275913.8030304@gmail.com> Date: Sun, 12 Aug 2012 08:19:47 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karl Auer Subject: Re: DAD question References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> <1344721144.6453.29.camel@karl> In-Reply-To: <1344721144.6453.29.camel@karl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 07:19:58 -0000 On 11/08/2012 22:39, Karl Auer wrote: > On Sat, 2012-08-11 at 18:01 +0200, sthaug@nethelp.no wrote: >> Duplicate MAC addresses are regularly seen in the wild. > > It's important to remember that DAD is link local. It is only checking > whether the same address occurs on the local link. Duplicate MAC > addresses are not actually a problem as long as the duplicates are not > on the same link. I think they are a problem for sites that register MAC addresses and use them as a first-line authentication mechanism. Obviously that is very weak from a security point of view, but it's common practice. Brian From brian.e.carpenter@gmail.com Sun Aug 12 00:23:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0845F11E80D5 for ; Sun, 12 Aug 2012 00:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.495 X-Spam-Level: X-Spam-Status: No, score=-101.495 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KZe6sEef+Um for ; Sun, 12 Aug 2012 00:23:42 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05F3611E809B for ; Sun, 12 Aug 2012 00:23:41 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1674997wgb.13 for ; Sun, 12 Aug 2012 00:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7nGeNQRyI6onRTHO4gKEgyts4U4L0uPZx/lCQTyX1Co=; b=BhtBBGlDezXl3KtUNCZlRb6+U/I1v7Fn4i15RpncCGQLOZGlmfPpJVahMdZTQYOuN9 293pPszwJw8wQRQPyBUDSismhTI4WXrE7giH77JkyM005qxpCPa/jpZMtXOkU6xHkpr2 c102dTLbFQe2Rsuh7Xn7QZtVyScc5sm9+0Kq8QX93DOr/3urlTYHjPJWKnz9KzCZr42w UOqhNMVSgiF861E+k7O6Qicwh+ue0bmFypIkVK7h0Lqlvs+NrGlEuyCQTX2CrmtQRMvu eEH5VUzfwLs/rM/jnyEPzOmAbbZJWf+3Mtol4kn3HvwipXB8QjSb3AXpliTf4BhOKqaL 0cvw== Received: by 10.180.81.66 with SMTP id y2mr8824244wix.22.1344756220577; Sun, 12 Aug 2012 00:23:40 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-150.as13285.net. [2.102.217.150]) by mx.google.com with ESMTPS id fb20sm12572406wid.1.2012.08.12.00.23.39 (version=SSLv3 cipher=OTHER); Sun, 12 Aug 2012 00:23:39 -0700 (PDT) Message-ID: <502759FA.3050009@gmail.com> Date: Sun, 12 Aug 2012 08:23:38 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler Subject: Re: draft-ietf-6man-uri-zoneid-02 References: , <5024B8F9.5090908@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B74DCD5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <50260C5A.7040006@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B74E6D4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B74E6D4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 07:23:43 -0000 On 11/08/2012 18:14, Dave Thaler wrote: >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of >> Brian E Carpenter >> Sent: Saturday, August 11, 2012 3:40 AM >> To: Dave Thaler >> Cc: Bob Hinden; ipv6@ietf.org >> Subject: Re: draft-ietf-6man-uri-zoneid-02 >> >> Dave, >> >> On 11/08/2012 03:59, Dave Thaler wrote: >>> Brian Carpenter writes: >>>> On 09/08/2012 22:31, Stuart Cheshire wrote: >>>>> At the meeting in Vancouver, Dave Thaler made a point that I found >>>>> convincing: >>>>> >>>>> Where is the character set for IPv6 zone IDs specified? >>>> RFC 4007 doesn't do so, but can be read to imply ASCII. >>> How? RFC 4007 says: >>>> An implementation MAY support other kinds of non-null strings as >>>> . However, the strings must not conflict with the delimiter >>>> character. The precise format and semantics of additional strings is >>>> implementation dependent. >> Yes, it says that, but the context to me implies ASCII. We could argue about >> that for a long time, so let's not bother... >> >>> So it's completely implementation dependent, the only restriction >>> being that % and null are disallowed. >>> >>>> draft-ietf-6man-uri-zoneid-02 is explicit that it refers to the URI >>>> character set, which is ASCII: >>>> >>>> A SHOULD contain only ASCII characters classified >>>> in RFC 3986 as "unreserved". >> The draft isn't clear enough (yet) but my idea was that this was part of the >> update to RFC 4007. > > During the Vancouver meeting, the chairs called the question of > whether to Update 4007 or not. The clear sense of the room was not > to do so. Assuming that consensus continues to hold on the list, I believe > this means the sentence you quote needs to be removed, and we cannot > place any restrictions on zone_id that aren't in 4007. In fact I agree that it's best to limit the scope of the current draft to solving the URI problem one way or another. I believe that RFC 4007 is in need of attention, but that should be handled separately. Brian > > -Dave > >>>> But it allows percent encoding in a URI, which is necessary because >>>> of the SHOULD: >>>> >>>> ZoneID = 1*( unreserved / pct-encoded ) >>> ZoneID needs to allow (including via percent-encoding) the same >>> characters as are allowed in in RFC 4007. For example the ']' >>> character would be legal in RFC 4007 but would have to be percent >>> encoded in a URI. >> Yes >> >>>>> If we accept >>>>> that future interface names might include non-roman characters, then >>>>> we have to assume that to allow safe unambiguous use in URIs, >>>>> interface names have to undergo escaping. >>>> If we want to internationalise the ZoneID, that would be a whole >>>> other discussion. >>> It's already allowed by RFC 4007 as far as I know. >> Well, again, it's a matter of interpretation; the question is simply not >> addressed, which is a defect in the document IMHO. >> >>> Stuart's email is an accurate summary of my position. >> Yes, but that doesn't help with the %251 problem, which is where we got >> stuck some months ago and came to the initial decision to add a new >> delimiter. If people don't want to solve that problem, i.e. accept that %251 in >> a URI is %1 in ping, and that %251 in ping is %25251 in a URI, then we're done. >> >> I'm here as a document editor, looking for guidance. >> >> Brian >> >> Brian >> >>> -Dave >>> >>>>> And if the interface name itself is going to be escaped using URI "%xx" >>>>> notation, then why not escape the '%' the same way? >>>> My impression is that this WG has already objected to that, which is >>>> why we ended up with the current proposal. I leave the next step to the >> WG Chair. >>>> Brian >>>> >>>>> This argues in support of what Microsoft already did: Encode '%' as >> "%25". >>>>> It's not my favourite outcome, but based on Dave Thaler's comment, >>>>> it's the one that gets my vote. >>>>> >>>>> In the spirit of "be liberal with what you accept" the doc should >>>>> also advocate that URI parsers are forgiving about accepting bare >>>>> '%' signs >>>>> -- i.e. a '%' not followed by two valid hex characters is left >>>>> untouched. This lets a human user copy-and-paste "fe80::a%en1" from >>>>> a "ping" command and have it work, though the strictly correct form >>>>> (which URI generators should output) remains "fe80::a%25en1". >>>>> >>>>> Stuart Cheshire >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > From mcr+ietf@sandelman.ca Sun Aug 12 09:20:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD86621F85B4 for ; Sun, 12 Aug 2012 09:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBqZAHOL8dcJ for ; Sun, 12 Aug 2012 09:20:33 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4E621F85AD for ; Sun, 12 Aug 2012 09:20:33 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 48A84202B8; Sun, 12 Aug 2012 12:33:34 -0400 (EDT) From: Michael Richardson To: Bob Hinden Subject: Re: DAD question In-Reply-To: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Cc: "ipv6@ietf.org 6man" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 16:20:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Bob" =3D=3D Bob Hinden writes: Bob> True, but the odds of this happening are very low. I wonder if Bob> we have any data on DAD detecting duplicate addresses and their Bob> cause.=20 In my experience, MAC address duplicates are almost always the result of too-true copy&paste'ing of virtual machine configurations :-) (You want to duplicate the virtual machine in order to try an upgrade...) Bob> For example, has any seen any actual duplicate MAC addresses? Bob> It would be good to collect some data.=20 if you remove 00:00:00:00:00:00 and ff:ff:ff:ff:ff:ff from the list, I've never seen a duplicate. (all-zeros and all-ones are the result of the eeprom dying in various ways, or a driver getting confused. Both will work until you get a second machine with the same problem) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCfXyIqHRg3pndX9AQJwDwQAtkdHAYQc+fDfbjTU8q9VO7Ci0CzL5DPN 1z5t/UxLV+li9KB3r5wtfL2jAzSj8oXsTsYSfrCgJVuLUIheL4Df7QG/3tlVSECb ZtaIt8yiDpGD0yKO7td44y13uXef5dezMKNnUqVssYPCRIU3Km4uHXdviFmkxVcH QNvMk/YvYL8= =Pyk0 -----END PGP SIGNATURE----- --=-=-=-- From bob.hinden@gmail.com Sun Aug 12 10:04:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE6E21F8593 for ; Sun, 12 Aug 2012 10:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYttuKALnyRz for ; Sun, 12 Aug 2012 10:04:12 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A60721F8569 for ; Sun, 12 Aug 2012 10:04:12 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1833115wgb.13 for ; Sun, 12 Aug 2012 10:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=n0f4fFdFHn28QBN73QXo06oCuQxRMh6kft4Zhxlcafg=; b=wxGVBMJCvQvM22LaYNqPkYA4gM9L3o9c+EZk35Y96P0xkGTTQ2G2HPkJtYpuT7Uax/ 55A9TE7TjMaioGCnQwcEOwlqmO7/OFKhY8FxYsDZga1EB/LfpRB+3dY52KpNsYKigVGU bctrRE5zLF4bLXM5aOFoHMYDyZA264NoEmcxfy3kP2wLmoUs+eT7wH+JuQlnFtg+EoFF OrqGT/7KsSDoGuQzJEnQfGvNoMOcCNFU0F1TsfKLRWbWrb+qKX2cA7/uyxciBXukxu5s urOqSC3qSuROdhd/umTlbAmiU3xTE54Ngo/CUwVzCLpSCJ83luUyWvZ9HNBbadqoFd37 dgKA== Received: by 10.216.41.195 with SMTP id h45mr5189911web.74.1344791051755; Sun, 12 Aug 2012 10:04:11 -0700 (PDT) Received: from [10.0.0.38] (c-24-130-151-138.hsd1.ca.comcast.net. [24.130.151.138]) by mx.google.com with ESMTPS id ck9sm16570100wib.2.2012.08.12.10.04.08 (version=SSLv3 cipher=OTHER); Sun, 12 Aug 2012 10:04:10 -0700 (PDT) Subject: Re: DAD question Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <18699.1344788424@obiwan.sandelman.ca> Date: Sun, 12 Aug 2012 10:04:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4522B70B-26F3-4BDA-A2A6-2D2F572F379A@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <18699.1344788424@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1280) Cc: "ipv6@ietf.org 6man" , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 17:04:13 -0000 Michael, On Aug 12, 2012, at 9:20 AM, Michael Richardson wrote: > >>>>>> "Bob" == Bob Hinden writes: > Bob> True, but the odds of this happening are very low. I wonder if > Bob> we have any data on DAD detecting duplicate addresses and their > Bob> cause. > > In my experience, MAC address duplicates are almost always the result of > too-true copy&paste'ing of virtual machine configurations :-) > (You want to duplicate the virtual machine in order to try an upgrade...) > > Bob> For example, has any seen any actual duplicate MAC addresses? > Bob> It would be good to collect some data. > > if you remove 00:00:00:00:00:00 and ff:ff:ff:ff:ff:ff from the list, > I've never seen a duplicate. (all-zeros and all-ones are the result of > the eeprom dying in various ways, or a driver getting confused. Both > will work until you get a second machine with the same problem) > Thanks, very helpful. Bob From randy@psg.com Sun Aug 12 10:15:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC3021F8622 for ; Sun, 12 Aug 2012 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXylzHwSMwsg for ; Sun, 12 Aug 2012 10:15:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A28AF21F8617 for ; Sun, 12 Aug 2012 10:15:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T0bkv-000DFN-6a; Sun, 12 Aug 2012 17:15:13 +0000 Date: Sun, 12 Aug 2012 13:15:28 -0400 Message-ID: From: Randy Bush To: Bob Hinden Subject: Re: DAD question In-Reply-To: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "ipv6@ietf.org 6man" , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 17:15:16 -0000 > For example, has any seen any actual duplicate MAC addresses? they have been rife. discussed on ops lists. randy From sthaug@nethelp.no Sun Aug 12 13:15:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A0E21F84A0 for ; Sun, 12 Aug 2012 13:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+DACzdjyQA1 for ; Sun, 12 Aug 2012 13:15:42 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id C897521F849B for ; Sun, 12 Aug 2012 13:15:41 -0700 (PDT) Received: (qmail 41090 invoked from network); 12 Aug 2012 20:15:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Aug 2012 20:15:39 -0000 Date: Sun, 12 Aug 2012 22:15:39 +0200 (CEST) Message-Id: <20120812.221539.74713824.sthaug@nethelp.no> To: mcr+ietf@sandelman.ca Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: <18699.1344788424@obiwan.sandelman.ca> References: <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <18699.1344788424@obiwan.sandelman.ca> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 20:15:43 -0000 > In my experience, MAC address duplicates are almost always the result of > too-true copy&paste'ing of virtual machine configurations :-) > (You want to duplicate the virtual machine in order to try an upgrade...) Here are a couple of counterexamples, taken from the list of 10 MAC addresses in my previous message. Both duplicates apparently due to software error, both affecting Linksys routers: 1. Googling "mac address 00:90:4c:91:00:01" gives me for instance http://homecommunity.cisco.com/t5/Access-Points/WAP54G-MAC-address-overwritten-how/td-p/26679 http://forum.soft32.com/linux2/Linksys-WAP54G-spontaneously-MAC-ftopict40391.html 2. Googling "mac address 00:40:10:20:00:02" gives me for instance http://www.dd-wrt.com/phpBB2/viewtopic.php?p=16097&sid=81aa5d3a28eb9718427591418ea20e3e http://secure.dd-wrt.com/phpBB2/viewtopic.php?t=53350&view=next&sid=c927780443f32c982cf9dd57d73ae952 Steinar Haug, Nethelp consulting, sthaug@nethelp.no From jeremy.duncan@salientfed.com Fri Aug 10 15:32:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECD211E80E4 for ; Fri, 10 Aug 2012 15:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j+hwr68YLQH for ; Fri, 10 Aug 2012 15:32:48 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2C03C11E80DB for ; Fri, 10 Aug 2012 15:32:46 -0700 (PDT) Received: from mail210-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Aug 2012 22:32:45 +0000 Received: from mail210-ch1 (localhost [127.0.0.1]) by mail210-ch1-R.bigfish.com (Postfix) with ESMTP id BBF9360128; Fri, 10 Aug 2012 22:32:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h944hd24hf0ah107ah17ej) Received-SPF: pass (mail210-ch1: domain of salientfed.com designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=jeremy.duncan@salientfed.com; helo=BY2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail210-ch1 (localhost.localdomain [127.0.0.1]) by mail210-ch1 (MessageSwitch) id 1344637962949094_22336; Fri, 10 Aug 2012 22:32:42 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail210-ch1.bigfish.com (Postfix) with ESMTP id DB72B340061; Fri, 10 Aug 2012 22:32:42 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Aug 2012 22:32:42 +0000 Received: from BY2PRD0510MB366.namprd05.prod.outlook.com ([169.254.6.34]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0175.005; Fri, 10 Aug 2012 22:32:41 +0000 From: "Duncan, Richard (Jeremy)" To: Jared Mauch , "ipv6@ietf.org" Subject: Re: DAD question Thread-Topic: DAD question Thread-Index: AQHNd0XlCeAhXXPBcEK2v5tAiE4SZZdTndWAgAADuYY= Date: Fri, 10 Aug 2012 22:32:40 +0000 Message-ID: References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [::] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: salientfed.com X-Mailman-Approved-At: Sun, 12 Aug 2012 13:25:47 -0700 Cc: "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:32:48 -0000 Fred- That's not the case at all. In testing I have done on Unix, Linux and Wind= ows systems they all do (1). There are a few variations with BSD, but for = the most part they just stop trying. In fact, RFC 4862 allows for that beh= avior and actually encourages it: 5.4.5. When Duplicate Address Detection Fails A tentative address that is determined to be a duplicate as described above= MUST NOT be assigned to an interface, and the node SHOULD log a system man= agement error. If the address is a link-local address formed from an interface identifier = based on the hardware address, which is supposed to be uniquely assigned (e= .g., EUI-64 for an Ethernet interface), IP operation on the interface SHOUL= D be disabled. By disabling IP operation, the node will then: - not send any IP packets from the interface, - silently drop any IP packets received on the interface, and - not forward any IP packets to the interface (when acting as a router or p= rocessing a packet with a Routing header). In this case, the IP address duplication probably means duplicate hardware = addresses are in use, and trying to recover from it by configuring another = IP address will not result in a usable network. In fact, it probably makes = things worse by creating problems that are harder to diagnose than just dis= abling network operation on the interface; the user will see a partially wo= rking network where some things work, and other things do not. On the other hand, if the duplicate link-local address is not formed from a= n interface identifier based on the hardware address, which is supposed to = be uniquely assigned, IP operation on the interface MAY be continued. 010100110110010101101101011100000110010101110010001000000100011001101001 Jeremy Duncan Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc. (Now including SGIS & Command Information I= nc.) 4000 Legato Road, Suite 600 Fairfax, VA 22033 Google Voice: 540.440.1193 jeremy.duncan@salientfed.com Jared Mauch wrote: On Aug 10, 2012, at 6:17 PM, Fred Baker (fred) wrote: > Is it fair to assume that implementations do DAD and follow (2)? This is the logical thing that I personally would do.. - Jared -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From sthaug@nethelp.no Sun Aug 12 13:29:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2F021F8674 for ; Sun, 12 Aug 2012 13:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu2cLmdx2m9C for ; Sun, 12 Aug 2012 13:29:49 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 6C3C721F866D for ; Sun, 12 Aug 2012 13:29:48 -0700 (PDT) Received: (qmail 41470 invoked from network); 12 Aug 2012 20:29:47 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Aug 2012 20:29:47 -0000 Date: Sun, 12 Aug 2012 22:29:47 +0200 (CEST) Message-Id: <20120812.222947.41669274.sthaug@nethelp.no> To: bob.hinden@gmail.com Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: References: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 20:29:49 -0000 > > So from this sample a total of 10 MAC addresses occur more than once > > (different customers, different locations). > > Interesting. Are these different machines/interfaces with the same Mac addresses, or the same machine connecting via some other path or location. I have duplicates on different BRAS boxes in widely different geographical locations, plus these are almost exclusively residential users. That makes it highly unlikely that they are the same machine connecting via some other path/location. > My question was about machines/interfaces. That is, are we seeing manufacturing mistakes, etc.? Explicit manufacturing mistakes (e.g. vendor turning our X copies of the same box with the same MAC address) have been reported on ops lists several times in the past. Software errors resulting in duplicates have been reported multiple times (see for instance my reply to Michael Richardson on this list). The possibility of explicitly configuring the MAC address exists in many operating systems (e.g. the FreeBSD box I'm typing this on). The easy availability of "MAC address cloning" was mentioned by Mikael Abrahamsson. Note that "MAC address cloning" is used in home routers, not just in VM environments. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From kauer@biplane.com.au Sun Aug 12 14:12:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30EB21F8611 for ; Sun, 12 Aug 2012 14:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hheS98EByNel for ; Sun, 12 Aug 2012 14:12:50 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id D318E21F861F for ; Sun, 12 Aug 2012 14:12:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABMbKFCWZX+7/2dsb2JhbAANN4YBtyEBAQEEI2YLGAICJgICSQENGatTbpF9gSGNBoIKgRIDoFiHdA Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 13 Aug 2012 06:42:46 +0930 Message-ID: <1344805961.6453.34.camel@karl> Subject: Re: DAD question From: Karl Auer To: ipv6@ietf.org Date: Mon, 13 Aug 2012 07:12:41 +1000 In-Reply-To: References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> , Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 21:12:51 -0000 On Fri, 2012-08-10 at 22:32 +0000, Duncan, Richard (Jeremy) wrote: > That's not the case at all. In testing I have done on Unix, Linux and > Windows systems they all do (1). 5.4.5. When Duplicate Address > Detection Fails > A tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface, and the node SHOULD log a system management error. My experience with Linux is that a duplicate LLA resukts in a down interface, a duplicate GUA results in a permanently-tentative enabled interface. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From cabo@tzi.org Sun Aug 12 14:27:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B179821F868A for ; Sun, 12 Aug 2012 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B5XydoMWgcg for ; Sun, 12 Aug 2012 14:27:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 045D921F84FB for ; Sun, 12 Aug 2012 14:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q7CLRdUT013787; Sun, 12 Aug 2012 23:27:39 +0200 (CEST) Received: from [192.168.217.105] (p5489298A.dip.t-dialin.net [84.137.41.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E7CA1B8D; Sun, 12 Aug 2012 23:27:38 +0200 (CEST) Subject: Re: DAD question Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20120812.222947.41669274.sthaug@nethelp.no> Date: Sun, 12 Aug 2012 23:27:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4AEE4E56-3B21-4027-A401-893835BC12CA@tzi.org> References: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120811.180104.41668882.sthaug@nethelp.no> <20120812.222947.41669274.sthaug@nethelp.no> To: bob.hinden@gmail.com X-Mailer: Apple Mail (2.1485) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 21:27:48 -0000 On Aug 12, 2012, at 22:29, sthaug@nethelp.no wrote: > Explicit manufacturing mistakes (e.g. vendor turning our X copies of > the same box with the same MAC address) have been reported on ops > lists several times in the past. Counterfeiting of network hardware may be another source of problems. A counterfeiter has a strong incentive to use an inconspicuous MAC = address, i.e. one that is indistinguishable from the real thing, and = they may hit the real thing as a result. Gr=FC=DFe, Carsten From j.schoenwaelder@jacobs-university.de Mon Aug 13 02:25:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246AC21F8732 for ; Mon, 13 Aug 2012 02:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV1TiRsVVg75 for ; Mon, 13 Aug 2012 02:25:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACEA21F871E for ; Mon, 13 Aug 2012 02:25:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15631209DC; Mon, 13 Aug 2012 11:25:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LM9seofQ2649; Mon, 13 Aug 2012 11:25:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BF62207B1; Mon, 13 Aug 2012 11:25:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 52B67211DBE2; Mon, 13 Aug 2012 11:25:04 +0200 (CEST) Date: Mon, 13 Aug 2012 11:25:04 +0200 From: Juergen Schoenwaelder To: Stuart Cheshire Subject: Re: draft-ietf-6man-uri-zoneid-02 Message-ID: <20120813092504.GA7172@elstar.local> Mail-Followup-To: Stuart Cheshire , ipv6@ietf.org, Bob Hinden , Dave Thaler References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Bob Hinden , ipv6@ietf.org, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 09:25:07 -0000 On Thu, Aug 09, 2012 at 02:31:24PM -0700, Stuart Cheshire wrote: > At the meeting in Vancouver, Dave Thaler made a point that I found > convincing: > > Where is the character set for IPv6 zone IDs specified? If we accept > that future interface names might include non-roman characters, then > we have to assume that to allow safe unambiguous use in URIs, > interface names have to undergo escaping. > > And if the interface name itself is going to be escaped using URI "%xx" > notation, then why not escape the '%' the same way? > > This argues in support of what Microsoft already did: Encode '%' as > "%25". > > It's not my favourite outcome, but based on Dave Thaler's comment, > it's the one that gets my vote. +1 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ichiroumakino@gmail.com Mon Aug 13 05:42:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F07821F8731 for ; Mon, 13 Aug 2012 05:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G0nLlKFfKwz for ; Mon, 13 Aug 2012 05:42:38 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2766621F8702 for ; Mon, 13 Aug 2012 05:42:37 -0700 (PDT) Received: by eekb45 with SMTP id b45so962962eek.31 for ; Mon, 13 Aug 2012 05:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:date:message-id:to:mime-version :x-mailer; bh=/WK/XSFiCUkmrhOhJvIRrbUUtressRmWow1wam6sCAk=; b=nBu12VfKNklafcnwXCgZLJlFPYIoU7u2bIfYmL3GN47Z8H2oHVbkcjweAL2vaB6Fs1 761FeIr0XBmaJF2toZSCbRIigWsemBc5IpkiZNSH8YuFUa8/gHD9ooOwyZ6ymBoDBaVg ee+T+mXEBD94nm7GJhVdNKH5WxXfTe6mJK+ZNubMczOHYW2Opa0Ybz552vwm8YQIGhMM KbsokpgYQGx0WDheMcqpUdeR+XPBVP5iW/wW9+jh3oDLkVl0yDepcAciW5hWRlYvaA+/ 7zyX6/O1zoH97++zUgWU1Lq6IiNUKNMea1VgSXS7bH9AQdikj9U5uOXUo0qCYqUMzlAB vLTQ== Received: by 10.14.179.200 with SMTP id h48mr14025958eem.12.1344861757130; Mon, 13 Aug 2012 05:42:37 -0700 (PDT) Received: from dhcp-10-61-98-250.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id h2sm18699719eeo.3.2012.08.13.05.42.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2012 05:42:36 -0700 (PDT) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/signed; boundary="Apple-Mail=_11B5CF2F-F7E5-4F09-8E88-A7D9295705D4"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: IETF84 - 6man minutes Date: Mon, 13 Aug 2012 14:42:35 +0200 Message-Id: To: "ipv6@ietf.org 6man" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 12:42:39 -0000 --Apple-Mail=_11B5CF2F-F7E5-4F09-8E88-A7D9295705D4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii all, the minutes from the 6man working group session is now available at: http://www.ietf.org/proceedings/84/minutes/minutes-84-6man cheers, Ole --Apple-Mail=_11B5CF2F-F7E5-4F09-8E88-A7D9295705D4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODEzMTI0MjM2WjAjBgkqhkiG9w0BCQQxFgQUoN/oF7gEWPUkMhY7 gAVxLZCmUkUwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEATQiTwPg5vJ3ID4H4OrtY MA2oRxOmV9rFNp9qOwDCM65a3xYp9A/bgLI42n5wIiWM6IbLh+s8uAsovjkeg9swT2HQ3flSNV7E nwiKn6kZetQkHoVh5t7Fb22GxXeUzxgZkIyt8kKzjJcwunM3sRYDK1SyBHHy72XomJZiyzsq19jY 7MTGM53saAMSg5ij2W5kqP9QotgIHv2wywgmpWxjEGoNCPX8Zq73q2VBt4FnvVzp+orLr3VGofyA G9MyZ7vpkEBopBPizQODHw9Sv1tRyfJ4QhE6SJlJUPMrrjl33dAjj7E94g5m43un5ebdasBhqJVo P0TgJX6+q48nEqPEswAAAAAAAA== --Apple-Mail=_11B5CF2F-F7E5-4F09-8E88-A7D9295705D4-- From brian.e.carpenter@gmail.com Mon Aug 13 06:19:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B473521F8759 for ; Mon, 13 Aug 2012 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.5 X-Spam-Level: X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFziRzKSZFDf for ; Mon, 13 Aug 2012 06:19:49 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8A21F874F for ; Mon, 13 Aug 2012 06:19:48 -0700 (PDT) Received: by eekb45 with SMTP id b45so976762eek.31 for ; Mon, 13 Aug 2012 06:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=sjcjXDpVgimo5aSXTps4gtncC8/g66hvxVQTFPiJWIc=; b=RNU3slLuQGmFJW9taC2GLT5Qes0VG/+zBAKpV8Eicr1Lm5ymiAneKxqmWfHSHK1W2q 9MtVdcLpqvioBf/wS+lodmtn/IM7QaYJ0EIyHvh52GzCi82/e7YUPfOayGSOuq77tpf1 3VoPsuO0h1QtuwwlmE18ESe0J3To/FYRgGbx7M0+qHoSxDqWOTlBbXHtznuSVaBi+CYI gi801e7Uj6DQs7hVRLoG1Q8zO0IXQ4vXrLU3PmdcXymQXks49NrjV6MRMMz2Tibkivvq W/pOHZvecJAv7bCaJAMtuzuhgOD1zTfAWOxhT3bcFKL5uLh4mESu6BNLU3z8wpJik0MS ACNQ== Received: by 10.14.202.66 with SMTP id c42mr14046057eeo.35.1344863988261; Mon, 13 Aug 2012 06:19:48 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-119.as13285.net. [2.102.216.119]) by mx.google.com with ESMTPS id k41sm18932079eep.13.2012.08.13.06.19.46 (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 06:19:47 -0700 (PDT) Message-ID: <5028FEF2.1040306@gmail.com> Date: Mon, 13 Aug 2012 14:19:46 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-00.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 13:19:49 -0000 Hi, We'd like comments on this new draft - hopefully it explains why we think it's needed. Brian & Sheng -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-ext-transmit-00.txt Date: Mon, 13 Aug 2012 06:09:18 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Extension Headers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-carpenter-6man-ext-transmit-00.txt Pages : 7 Date : 2012-08-13 Abstract: Various IPv6 extension headers have been defined since the IPv6 standard was first published. This document updates RFC 2460 to describe how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bs7652@att.com Mon Aug 13 07:30:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359A821F8759 for ; Mon, 13 Aug 2012 07:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV5D-K+r+qN1 for ; Mon, 13 Aug 2012 07:30:14 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4004421F8751 for ; Mon, 13 Aug 2012 07:30:13 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 67f09205.7fd06940.219979.00-598.578200.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 13 Aug 2012 14:30:14 +0000 (UTC) X-MXL-Hash: 50290f76320c2b21-ec3757b570dce9858e7c1d18df897d897b45ea3f Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 17f09205.0.219951.00-469.578076.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 13 Aug 2012 14:30:09 +0000 (UTC) X-MXL-Hash: 50290f710128f918-fbcd540ff62be9d726957954b57fefed81568759 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7DEU7C3016015; Mon, 13 Aug 2012 10:30:09 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7DETptX015123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 10:30:02 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 13 Aug 2012 10:28:30 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 10:28:30 -0400 From: "STARK, BARBARA H" To: "Fred Baker (fred)" , "ipv6@ietf.org 6man" Subject: RE: DAD question Thread-Topic: DAD question Thread-Index: AQHNd0XlCeAhXXPBcEK2v5tAiE4SZZdXtNpA Date: Mon, 13 Aug 2012 14:28:28 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61115E277@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> In-Reply-To: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.136.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=-5zszckSLQMA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=yM] X-AnalysisOut: [hMjlubAAAA:8 a=pObygEVbZNboA842jkcA:9 a=CjuIK1q_8ugA:10 a=] X-AnalysisOut: [mFTNPgy23_KintRF:21 a=62DXDsYdUm8jPnnD:21] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:30:15 -0000 > My question is: what happens if any of them discovers that it has created= an > address that is already in use in the network? >=20 > There would appear to be two options: > (1) "ah, OK, I guess I didn't really want to talk today" > (2) Following RFC 4941, guess again until one creates a unique address >=20 > Is it fair to assume that implementations do DAD and follow (2)? >From the perspective of the CE router... BBF decided on the following recommendation: If DAD (on the WAN) fails for link-local or SLAAC, "vendor should implement= graceful handling, including trying other addresses". Router vendors felt this provided reasonable advice without limiting how th= ey accomplished it. Some thought it would be reasonable to try using MAC ad= dresses associated with other interfaces (from a LAN Ethernet or Wi-Fi inte= rface), increment the previously tried value by 1 or x, and other possibili= ties. Once there was greater experience with real deployments, where it cou= ld be seen what worked and was easy, there would probably be convergence on= "best practices". But it was acknowledged that (1) such duplication of MA= C addresses exists and is reasonably prevalent (all service providers see t= his), (2) it is unlikely that we can stop this from happening, (3) allowing= such a CE router to become a brick would generate trouble calls and serve = no useful purpose, and (4) implementing code that would try a different val= ue was simple and had no perceived downside (as long as all CE routers had = code to try other values).=20 As has been pointed out, using 1:1 VLAN would prevent this problem. But my = perspective is that the CE router doesn't know what access network it will = land in, and needs to be resilient when finding itself in a N:1 VLAN enviro= nment. As Ole pointed out, RFC 4941 explicitly mandates generation of a different = privacy address when DAD fails. RFC 3315 recommends use of DAD and telling the DHCPv6 server (Decline) if D= AD fails. But this case isn't perceived to be a problem (unless the DHCPv6 = server is misconfigured or someone managed to get that IPv6 Attack Toolkit = that Dominik mentioned into the access network -- in which case we have big= ger problems). A bigger problem for DHCPv6 servers may be the one of duplic= ate DUIDs, which may cause a DHCPv6 server to refuse to provide a IA_NA. Th= is apparently is sufficiently prevalent that Microsoft had to provide info = on how to fix it: http://support.microsoft.com/kb/2711727 Barbara From internet-drafts@ietf.org Mon Aug 13 23:48:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4943411E80D9; Mon, 13 Aug 2012 23:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExGH4geHtlAh; Mon, 13 Aug 2012 23:48:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDE311E808E; Mon, 13 Aug 2012 23:48:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-lineid-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120814064850.12326.12959.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 23:48:50 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 06:48:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : The Line Identification Destination Option Author(s) : Suresh Krishnan Alan Kavanagh Balazs Varga Sven Ooghe Erik Nordmark Filename : draft-ietf-6man-lineid-06.txt Pages : 16 Date : 2012-08-13 Abstract: In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the edge router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-lineid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-lineid-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-lineid-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Tue Aug 14 02:08:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F346621F86B3 for ; Tue, 14 Aug 2012 02:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfx15INVtDnX for ; Tue, 14 Aug 2012 02:08:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 39B5021F86A4 for ; Tue, 14 Aug 2012 02:08:24 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 771163B435C; Tue, 14 Aug 2012 11:08:23 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 59E7927C05B; Tue, 14 Aug 2012 11:08:23 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 14 Aug 2012 11:08:06 +0200 From: To: Suresh Krishnan Date: Tue, 14 Aug 2012 11:08:05 +0200 Subject: RE: I-D Action: draft-ietf-6man-lineid-06.txt Thread-Topic: I-D Action: draft-ietf-6man-lineid-06.txt Thread-Index: Ac156OGz+TOC6hWyQqeYQMGJAZMuEAAEvCHw Message-ID: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C1@PUEXCB1B.nanterre.francetelecom.fr> References: <20120814064850.12326.12959.idtracker@ietfa.amsl.com> In-Reply-To: <20120814064850.12326.12959.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.14.60320 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:08:25 -0000 Dear Suresh, I checked the new version and see it does not implement what has been agree= d here: http://www.ietf.org/mail-archive/web/ipv6/current/msg15996.html Is there any particular reason for not adding that change? Thanks.=20 Cheers, Med=20 >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >Envoy=E9 : mardi 14 ao=FBt 2012 08:49 >=C0 : i-d-announce@ietf.org >Cc : ipv6@ietf.org >Objet : I-D Action: draft-ietf-6man-lineid-06.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance Working=20 >Group of the IETF. > > Title : The Line Identification Destination Option > Author(s) : Suresh Krishnan > Alan Kavanagh > Balazs Varga > Sven Ooghe > Erik Nordmark > Filename : draft-ietf-6man-lineid-06.txt > Pages : 16 > Date : 2012-08-13 > >Abstract: > In Ethernet based aggregation networks, several subscriber premises > may be logically connected to the same interface of an edge router. > This document proposes a method for the edge router to identify the > subscriber premises using the contents of the received Router > Solicitation messages. The applicability is limited to broadband > network deployment scenarios where multiple user ports are mapped to > the same virtual interface on the edge router. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-6man-lineid > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-6man-lineid-06 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-lineid-06 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >= From mohamed.boucadair@orange.com Tue Aug 14 02:09:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E350121F86C9 for ; Tue, 14 Aug 2012 02:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 392qsqjq4Zru for ; Tue, 14 Aug 2012 02:09:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1C18621F86C7 for ; Tue, 14 Aug 2012 02:09:43 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 8256926430D; Tue, 14 Aug 2012 11:09:42 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5DA4227C053; Tue, 14 Aug 2012 11:09:42 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 14 Aug 2012 11:09:25 +0200 From: To: "ipv6@ietf.org" Date: Tue, 14 Aug 2012 11:09:24 +0200 Subject: draft-ietf-mboned-64-multicast-address-format Thread-Topic: draft-ietf-mboned-64-multicast-address-format Thread-Index: Ac15/H+QIzoNoetUTnKJxZVT1kbyeA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E4FC2D8C2PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.14.60320 Cc: Jacni Qin , "draft-ietf-mboned-64-multicast-address-format@tools.ietf.org" , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:09:44 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E4FC2D8C2PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I'm initiating this thread in the hope of understanding the objections from the 6man WG and hopefully to make some progress for this document. To initiate the discussion, below are provided some preliminary Q/A: What is the scope of this document? The document specifies an algorithmic translation of an IPv6 multicast address to a corresponding IPv4 multicast address, and vice versa. The document reserves two IPv6 multicast prefixes to be used for that purpose. What are these reserved prefixes? * ff3x:0:8000::/96 for SSM * ffxx:8000::/20 for ASM Does this document update IPv6 addressing architecture? No. Is there a unicast counterpart of this proposal? Yes, RFC6052. What is the problem to be solved? There are several use cases as detailed in [I-D.ietf-mboned-v4v6- mcast-ps]. In particular, the following use cases are of interest: 1. An IPv6-only receiver wants to receive multicast content from an IPv4-only source (6-4). 2. An IPv4 receiver wants to join a multicast group in IPv4 domain via an IPv6-only network (4-6-4). Are there solutions for the unicast counterpart of these use cases? Yes; various solutions including: 1. 6-4: RFC6146 2. 4-6-4: RFC6333, RFC6346, ... The latest version of the document is available at: https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-0= 3. Comments and suggestions are more than welcome. Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E4FC2D8C2PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
I= 'm=20 initiating this thread in the hope of understanding the
objections from = the=20 6man WG and hopefully to make some progress for
this document.  To= =20 initiate the discussion, below are provided some
preliminary=20 Q/A:
 
W= hat is the=20 scope of this document?
   The document specifies an algorithm= ic=20 translation of an IPv6
   multicast address to a corresponding= IPv4=20 multicast address, and
   vice versa.  The document reser= ves=20 two IPv6 multicast prefixes to
   be used for that=20 purpose.
 
W= hat are=20 these reserved prefixes?
   *  ff3x:0:8000::/96 for=20 SSM
   *  ffxx:8000::/20 for ASM
 
D= oes this=20 document update IPv6 addressing architecture?
  =20 No.
 
I= s there a=20 unicast counterpart of this proposal?
   Yes,=20 RFC6052.
 
W= hat is the=20 problem to be solved?
   There are several use cases as detail= ed in=20 [I-D.ietf-mboned-v4v6-
   mcast-ps].  In particular, the= =20 following use cases are of
   interest:
   1.&nbs= p; An=20 IPv6-only receiver wants to receive multicast content=20 from
       an IPv4-only source=20 (6-4).
   2.  An IPv4 receiver wants to join a multicast = group=20 in IPv4
       domain via an IPv6-only net= work=20 (4-6-4).
 
A= re there=20 solutions for the unicast counterpart of these use cases?
   Y= es;=20 various solutions including:
   1.  6-4:=20 RFC6146
   2.  4-6-4: RFC6333, RFC6346,=20 ...
 
T= he latest=20 version of the document is available at:
<= A=20 href=3D"https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-= format-03">https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-addre= ss-format-03.
 
C= omments and=20 suggestions are more than welcome.
 
Cheers,
Med =20
--_000_94C682931C08B048B7A8645303FDC9F36E4FC2D8C2PUEXCB1Bnante_-- From Francis.Dupont@fdupont.fr Tue Aug 14 04:41:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A238321F84F6 for ; Tue, 14 Aug 2012 04:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SmWni13E1Qn for ; Tue, 14 Aug 2012 04:41:49 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 9120421F84E1 for ; Tue, 14 Aug 2012 04:41:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q7EBfiIe099885; Tue, 14 Aug 2012 13:41:44 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201208141141.q7EBfiIe099885@givry.fdupont.fr> From: Francis Dupont To: Fernando Gont Subject: Re: DAD question In-reply-to: Your message of Sat, 11 Aug 2012 14:16:41 -0300. <50269379.3010100@si6networks.com> Date: Tue, 14 Aug 2012 13:41:44 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "ipv6@ietf.org 6man" , Bob Hinden , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 11:41:49 -0000 I remember (perhaps the first detected duplicate?) a very early occurrence before 1995 with a DEC box using a cloned full config. Same Decnet address so same MAC address so same IPv6 link-local address... Regards Francis.Dupont@fdupont.fr PS: I can contact the person who found it if you need it for archives. From ietfc@btconnect.com Tue Aug 14 06:35:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15E21F8690 for ; Tue, 14 Aug 2012 06:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.185 X-Spam-Level: X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwtvZLsFDrhw for ; Tue, 14 Aug 2012 06:35:11 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 870CD21F8674 for ; Tue, 14 Aug 2012 06:35:10 -0700 (PDT) Received: from mail253-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 13:35:10 +0000 Received: from mail253-tx2 (localhost [127.0.0.1]) by mail253-tx2-R.bigfish.com (Postfix) with ESMTP id 0F88210802BF; Tue, 14 Aug 2012 13:35:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h304l) Received: from mail253-tx2 (localhost.localdomain [127.0.0.1]) by mail253-tx2 (MessageSwitch) id 1344951307804576_13686; Tue, 14 Aug 2012 13:35:07 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.238]) by mail253-tx2.bigfish.com (Postfix) with ESMTP id BC1FC640045; Tue, 14 Aug 2012 13:35:07 +0000 (UTC) Received: from DB3PRD0702HT004.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 13:35:06 +0000 Received: from SN2PRD0710HT001.namprd07.prod.outlook.com (157.56.234.149) by pod51017.outlook.com (10.3.4.154) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 14 Aug 2012 13:35:01 +0000 Message-ID: <034701cd7a20$f7845740$4001a8c0@gateway.2wire.net> From: t.petch To: Dave Thaler , Brian E Carpenter References: , <5024B8F9.5090908@gmail.com><9B57C850BB53634CACEC56EF4853FF653B74DCD5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><50260C5A.7040006@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B74E6D4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: draft-ietf-6man-uri-zoneid-02 Date: Tue, 14 Aug 2012 14:30:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.234.149] X-OriginatorOrg: btconnect.com Cc: Bob Hinden , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 13:35:12 -0000 ----- Original Message ----- From: "Dave Thaler" To: "Brian E Carpenter" Cc: ; "Bob Hinden" Sent: Saturday, August 11, 2012 6:14 PM > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > > Brian E Carpenter > > Sent: Saturday, August 11, 2012 3:40 AM > > To: Dave Thaler > > Cc: Bob Hinden; ipv6@ietf.org > > Dave, > > > > On 11/08/2012 03:59, Dave Thaler wrote: > > > Brian Carpenter writes: > > >> On 09/08/2012 22:31, Stuart Cheshire wrote: > > >>> At the meeting in Vancouver, Dave Thaler made a point that I found > > >>> convincing: > > >>> > > >>> Where is the character set for IPv6 zone IDs specified? > > >> RFC 4007 doesn't do so, but can be read to imply ASCII. > > > > > > How? RFC 4007 says: > > >> An implementation MAY support other kinds of non-null strings as > > >> . However, the strings must not conflict with the delimiter > > >> character. The precise format and semantics of additional strings is > > >> implementation dependent. > > > > Yes, it says that, but the context to me implies ASCII. We could argue about > > that for a long time, so let's not bother... > > > > > So it's completely implementation dependent, the only restriction > > > being that % and null are disallowed. > > > > > >> draft-ietf-6man-uri-zoneid-02 is explicit that it refers to the URI > > >> character set, which is ASCII: > > >> > > >> A SHOULD contain only ASCII characters classified > > >> in RFC 3986 as "unreserved". > > > > The draft isn't clear enough (yet) but my idea was that this was part of the > > update to RFC 4007. > > During the Vancouver meeting, the chairs called the question of > whether to Update 4007 or not. The clear sense of the room was not > to do so. Unfortunately, the minutes seem to have no recollection of this happening, although as you later say, it is what happens on the list that takes precedence. Had I been in the room, I would not have concurred. Tom Petch Minutes extract Bob Hinden presented the draft about Representing IPv6 Zone Identifiers in Uniform Resource Identifiers, (draft-ietf-6man-uri-zoneid-02.txt) ====================================================================== Erik Kline wanted to know if the authors have considered '@' as a separator. He also wanted to know how to ensure that the zone id was a valid production. Bob mentioned that it cannot be ensured. Dave Thaler mentioned that in windows the zone id was always an integer but it could be different for other OSs. Stuart Cheshire wanted this to be mentioned in the document as a guideline to OS implementers. He wanted to do what was best for the end users rather than what was best for the programmers. He believed that unless the zone id was greater than 250 there were no issues. Bob Hinden agreed with Stuart and thought that browsers could easily handle the special case. Dave Thaler thought that the whole justification about cut and paste was dubious, and he wanted the justification to be rewritten concerning other issues with using %. He talked about the validation of the stuff inside [] performed by RFC4007 validators. He wanted to make sure that he could reuse the validation code instead of writing two sets of code that could introduce bugs. Juergen Schoenwaelder did not see the value with using a new separator either. Stig Venaas wanted to mention that the % could become ambiguous if % escapable characters are already present in the interface names. Dave mentioned that if the text has any foreign characters cut and paste would not work anyway. Mark Andrews agreed with Stig concerning this being confusing to humans but not for computers. Stuart and Kerry thanked Bob for taking on this tough job. Bob believed that the authors had enough information to do another revision with the comments received during the meeting. ================================================== > Assuming that consensus continues to hold on the list, I believe > this means the sentence you quote needs to be removed, and we cannot > place any restrictions on zone_id that aren't in 4007. > > -Dave > > > >> But it allows percent encoding in a URI, which is necessary because > > >> of the SHOULD: > > >> > > >> ZoneID = 1*( unreserved / pct-encoded ) > > > > > > ZoneID needs to allow (including via percent-encoding) the same > > > characters as are allowed in in RFC 4007. For example the ']' > > > character would be legal in RFC 4007 but would have to be percent > > > encoded in a URI. > > > > Yes > > > > > > > >>> If we accept > > >>> that future interface names might include non-roman characters, then > > >>> we have to assume that to allow safe unambiguous use in URIs, > > >>> interface names have to undergo escaping. > > >> If we want to internationalise the ZoneID, that would be a whole > > >> other discussion. > > > > > > It's already allowed by RFC 4007 as far as I know. > > > > Well, again, it's a matter of interpretation; the question is simply not > > addressed, which is a defect in the document IMHO. > > > > > > > > Stuart's email is an accurate summary of my position. > > > > Yes, but that doesn't help with the %251 problem, which is where we got > > stuck some months ago and came to the initial decision to add a new > > delimiter. If people don't want to solve that problem, i.e. accept that %251 in > > a URI is %1 in ping, and that %251 in ping is %25251 in a URI, then we're done. > > > > I'm here as a document editor, looking for guidance. > > > > Brian > > > > Brian > > > > > > > > -Dave > > > > > >>> And if the interface name itself is going to be escaped using URI "%xx" > > >>> notation, then why not escape the '%' the same way? > > >> My impression is that this WG has already objected to that, which is > > >> why we ended up with the current proposal. I leave the next step to the > > WG Chair. > > >> > > >> Brian > > >> > > >>> This argues in support of what Microsoft already did: Encode '%' as > > "%25". > > >>> > > >>> It's not my favourite outcome, but based on Dave Thaler's comment, > > >>> it's the one that gets my vote. > > >>> > > >>> In the spirit of "be liberal with what you accept" the doc should > > >>> also advocate that URI parsers are forgiving about accepting bare > > >>> '%' signs > > >>> -- i.e. a '%' not followed by two valid hex characters is left > > >>> untouched. This lets a human user copy-and-paste "fe80::a%en1" from > > >>> a "ping" command and have it work, though the strictly correct form > > >>> (which URI generators should output) remains "fe80::a%25en1". > > >>> > > >>> Stuart Cheshire From evyncke@cisco.com Tue Aug 14 07:14:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F5621F86EE; Tue, 14 Aug 2012 07:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIX709Ss7ZNf; Tue, 14 Aug 2012 07:14:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3421F86E4; Tue, 14 Aug 2012 07:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=3712; q=dns/txt; s=iport; t=1344953654; x=1346163254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3Zo+KJz1J8KuLklYaNIU0ABBZSgtqdSBBqUGFIJzmrA=; b=FhZLvrS/DplTATxxZdO6vWpAc6a4tV+v9ExkFB006O1a82QG4WtHqn2c uIGSRs4v8gZliFc8lX1/fuBL0FQdbK2xSTI3HCVZHMC4yfX7U+F7eDyhK b4dmD4ufHzSdFmxOVZ6VJace6m2rAJkQ5zxXLY6Ku4KPna+zrcGZ2eclb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO1bKlCtJV2a/2dsb2JhbABEuhCBB4IgAQEBBAEBAQ8BWwsMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCAEZh2sLmCmgfosFhVFgA4gZjkaNFoFmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,766,1336348800"; d="scan'208";a="111433678" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2012 14:14:14 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7EEED1f029535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 14:14:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.72]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 09:14:13 -0500 From: "Eric Vyncke (evyncke)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: RE: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt Thread-Topic: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt Thread-Index: AQHNduSITSOnCBL6rUikafVYIuM39ZdZW8KA Date: Tue, 14 Aug 2012 14:14:13 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E10C4748@xmb-aln-x02.cisco.com> References: <20120810103916.17649.29017.idtracker@ietfa.amsl.com> In-Reply-To: <20120810103916.17649.29017.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.71] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.005 x-tm-as-result: No--44.149500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:14:15 -0000 Hello Fernando, A couple of quick comments: - section 2: I would love to have data to back the point of 'Many implement= ations fail to perform validation checks on the received ICMPv6 error messa= ges' (such as adding a reference to your appendix) - section 3: it would be nice to add some text about the case where a packe= t is duplicated by the network (could occur in rare circumstances) and one = copy is fragmented (not an atomic fragment) and the other copy is not (atom= ic fragment) because of different path - section 3: not sure what is meant by 'FH should (no uppercase?) be remove= d by the receiving host', on the contrary, I would prefer to keep the FH in= the packet (some apps may need it) but immediately deliver the full packet= to the upper layer - section 3: it would be nice if some explanations were given why a host re= ceiving such an atomic fragment should not discard the matching real fragme= nts... I tend to believe that upper layer (TCP notably) will reject the sec= ond one if the sequence number match May I also suggest to integrate this I-D into the more generic draft-gont-6= man-predictable-fragment-id ? It will make the task of implementers easier = if both I-D are merged. Hope it helps Regards -=E9ric > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: vendredi 10 ao=FBt 2012 12:39 > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance Working Group of the > IETF. >=20 > Title : Processing of IPv6 "atomic" fragments > Author(s) : Fernando Gont > Filename : draft-ietf-6man-ipv6-atomic-fragments-01.txt > Pages : 13 > Date : 2012-08-10 >=20 > Abstract: > The IPv6 specification allows packets to contain a Fragment Header > without the packet being actually fragmented into multiple pieces. > Such packets typically result from hosts that have received an ICMPv6 > "Packet Too Big" error message that advertises a "Next-Hop MTU" > smaller than 1280 bytes, and are currently processed by some > implementations as "fragmented traffic". Thus, by forging ICMPv6 > "Packet Too Big" error messages an attacker can cause hosts to employ > "atomic fragments", and then launch any fragmentation-based attacks > against such traffic. This document discusses the generation of the > aforementioned "atomic fragments", the corresponding security > implications, and formally updates RFC 2460 and RFC 5722 such that > fragmentation-based attack vectors against traffic employing "atomic > fragments" are completely eliminated. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-atomic-fragments-= 01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ichiroumakino@gmail.com Tue Aug 14 07:41:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0F21F846F for ; Tue, 14 Aug 2012 07:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.025 X-Spam-Level: X-Spam-Status: No, score=-3.025 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRIa160JkTzU for ; Tue, 14 Aug 2012 07:41:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3931921F854A for ; Tue, 14 Aug 2012 07:41:26 -0700 (PDT) Received: by eaai11 with SMTP id i11so188623eaa.31 for ; Tue, 14 Aug 2012 07:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:date:message-id:to:mime-version :x-mailer; bh=whwp2QZA7auKWLcKDCCjuVvbFhHWBUU5j0XHwkiAmI0=; b=TjliPQL7J4se/lsgAjNUlAvlJrnX7SwQIyvFUUZSgMSaiAdtSkWQED0pPO8iSnJFl9 2KPl/5Md7sM+Z4ELb9XB2ATxnqzKDRurc1T/7fAlIgShENTudcChnrYNYx96fqw3zqy8 g4TbCqdRQ35k6a2PdhGZ1qSvBlNxH46qm/DWZ3DEU9fEYRwdItcNBEzsTQ4DUyKqREAM l2HopM0TPm/mRRQk8SJiFVNwlG60SnrybEGnAqCo5k3Ao7g1ilIN+3t2hnPbQ3rMnx24 HumvQP9e1v4ny5icZa9A8VR6OmIFyO9cAK6IWg/RRSt35TkZX+9mhq1yzO4jx3uAGdQM vr0g== Received: by 10.14.182.134 with SMTP id o6mr19662487eem.26.1344955285192; Tue, 14 Aug 2012 07:41:25 -0700 (PDT) Received: from dhcp-10-61-100-113.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id g46sm7367357eep.15.2012.08.14.07.41.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 07:41:23 -0700 (PDT) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/signed; boundary="Apple-Mail=_1A725FD5-873C-4125-9385-5A95DCCAFE1A"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: Towards consensus on draft-ietf-6man-uri-zoneid Date: Tue, 14 Aug 2012 16:41:21 +0200 Message-Id: <406302CF-A5B2-410C-985E-203D7173E1D6@employees.org> To: "ipv6@ietf.org 6man" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:41:31 -0000 --Apple-Mail=_1A725FD5-873C-4125-9385-5A95DCCAFE1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii all, I fully accept that there are no perfect solution to this problem. given that we are were we are... it appears there is consensus building around Stuart's proposal. that entails: - encode '%' as "%25" - advocate that URI parsers are forgiving about accepting bare '%' i.e. a '%' not followed by two valid hex characters is left untouched - no update to RFC4007 - no new delimiter - interface names may themselves have to escaped (non-roman or [] = characters) please reply to the list if you support or disagree with the proposal = _and_ have additional arguments for discussion. (there is no need to reply with "+1" or "-1" without arguments.) Best regards, Ole= --Apple-Mail=_1A725FD5-873C-4125-9385-5A95DCCAFE1A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODE0MTQ0MTIxWjAjBgkqhkiG9w0BCQQxFgQUIIDfCFSP+PO5n0ku RdT6gXalPmUwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAf7IcvsmX7VicojJ8cNNE gfWyQozv8rGISv1AYh7IcbSGWaGxhlYJwaITPTRe0OdDtDXpGawX6Z2/ETOcGZLnH2SFAOtCJQ5h Yt25ccR+MbFxEvtaPjwgO1tFz6cySsVaar/jtwJp6hONMwytqshO+r9Jdn7+TnH/AI1s25LSDMnn VVCcSWc0m6iP+wWE03griQjPzibeO00y/tTyxo51McuYith6inLtHpzcxl3icMNoeFY8iWZIbevR MgMVmbWX+RvC7P5vIMZBGNhKqBG++NbphtVHICjPHrudMA/DsN0K1vQVc1pCta1jhTEIUu3Vd6SH gECDvrla2o3/ekH0EQAAAAAAAA== --Apple-Mail=_1A725FD5-873C-4125-9385-5A95DCCAFE1A-- From suresh.krishnan@ericsson.com Tue Aug 14 07:59:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD76521F865E for ; Tue, 14 Aug 2012 07:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShE0nR+rXwdc for ; Tue, 14 Aug 2012 07:59:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 10B6021F851B for ; Tue, 14 Aug 2012 07:59:41 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7EExpWI010533; Tue, 14 Aug 2012 09:59:55 -0500 Received: from [142.133.112.80] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.264.1; Tue, 14 Aug 2012 10:59:34 -0400 Message-ID: <502A67D6.6090808@ericsson.com> Date: Tue, 14 Aug 2012 10:59:34 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "mohamed.boucadair@orange.com" Subject: Re: I-D Action: draft-ietf-6man-lineid-06.txt References: <20120814064850.12326.12959.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E4FC2D8C1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C1@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:59:41 -0000 Hi Med, I have another pending change in the Applicability section and I am waiting for the reviewer to get back on the proposed text. That will help me put the draft in context. I will have a new rev out by end of today. Thanks Suresh On 08/14/2012 05:08 AM, mohamed.boucadair@orange.com wrote: > Dear Suresh, > > I checked the new version and see it does not implement what has been agreed here: > > http://www.ietf.org/mail-archive/web/ipv6/current/msg15996.html > > Is there any particular reason for not adding that change? > > Thanks. > > Cheers, > Med > >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] De la part de >> internet-drafts@ietf.org >> Envoyé : mardi 14 août 2012 08:49 >> À : i-d-announce@ietf.org >> Cc : ipv6@ietf.org >> Objet : I-D Action: draft-ietf-6man-lineid-06.txt >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the IPv6 Maintenance Working >> Group of the IETF. >> >> Title : The Line Identification Destination Option >> Author(s) : Suresh Krishnan >> Alan Kavanagh >> Balazs Varga >> Sven Ooghe >> Erik Nordmark >> Filename : draft-ietf-6man-lineid-06.txt >> Pages : 16 >> Date : 2012-08-13 >> >> Abstract: >> In Ethernet based aggregation networks, several subscriber premises >> may be logically connected to the same interface of an edge router. >> This document proposes a method for the edge router to identify the >> subscriber premises using the contents of the received Router >> Solicitation messages. The applicability is limited to broadband >> network deployment scenarios where multiple user ports are mapped to >> the same virtual interface on the edge router. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-lineid >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6man-lineid-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-lineid-06 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > From bob.hinden@gmail.com Tue Aug 14 08:33:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8AA21F8582 for ; Tue, 14 Aug 2012 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.677 X-Spam-Level: X-Spam-Status: No, score=-103.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuh0H-Iqlsrm for ; Tue, 14 Aug 2012 08:33:51 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E80A921F8514 for ; Tue, 14 Aug 2012 08:33:50 -0700 (PDT) Received: by eekb45 with SMTP id b45so207549eek.31 for ; Tue, 14 Aug 2012 08:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=B1rtOm8b+K5Xx+ARzStlgd7XBQ2tnoI6VMvYVe7uIsQ=; b=AlFaKwb2tMbitTZzupiiyXZ4hX/0IYyH9/3XVF7JdX5FCt6eeuGcAn5bWmKl8ouXdh 2j9nDw/wYb/XKHRgqrJSEnJryA4ArEYrFtFqaai25Gt7lIq+7riVlOiSXhDO37iO6s0j EaXZzSDfkxY16kv4PwhjVQe6xJfDkNsJuDmvUsjJYQ8ocJHK5GMWi5D8IcwzGskKsgsg zV5leISb9VhHKksHPr/iEVbcnrepSIleIvsynYU7XSh3kSpSVvgHSL+AGi5KO3gkWdjE CJL4u2W9h1K/Om8xbmv7u/SixmBM/pe/7voPhHxQYcLnr0KFk+dWIVhjkGQTS7bTU6Z1 t5Mw== Received: by 10.14.206.200 with SMTP id l48mr19965558eeo.41.1344958430155; Tue, 14 Aug 2012 08:33:50 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:8047:2250:7163:4297? ([2601:9:4080:10:8047:2250:7163:4297]) by mx.google.com with ESMTPS id h2sm7798567eeo.3.2012.08.14.08.33.21 (version=SSLv3 cipher=OTHER); Tue, 14 Aug 2012 08:33:48 -0700 (PDT) Subject: Re: draft-ietf-mboned-64-multicast-address-format Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 14 Aug 2012 08:33:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1280) Cc: "ipv6@ietf.org" , Bob Hinden , "draft-ietf-mboned-64-multicast-address-format@tools.ietf.org" , Jacni Qin , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 15:33:51 -0000 Med, The new draft appears to have many changes from the previous version. = It would be helpful if you could describe the changes. This is usually = done in the draft itself, but I didn't see it in -03. Thanks, Bob On Aug 14, 2012, at 2:09 AM, = wrote: > Dear all, > =20 > I'm initiating this thread in the hope of understanding the > objections from the 6man WG and hopefully to make some progress for > this document. To initiate the discussion, below are provided some > preliminary Q/A: > =20 > What is the scope of this document? > The document specifies an algorithmic translation of an IPv6 > multicast address to a corresponding IPv4 multicast address, and > vice versa. The document reserves two IPv6 multicast prefixes to > be used for that purpose. > =20 > What are these reserved prefixes? > * ff3x:0:8000::/96 for SSM > * ffxx:8000::/20 for ASM > =20 > Does this document update IPv6 addressing architecture? > No. > =20 > Is there a unicast counterpart of this proposal? > Yes, RFC6052. > =20 > What is the problem to be solved? > There are several use cases as detailed in [I-D.ietf-mboned-v4v6- > mcast-ps]. In particular, the following use cases are of > interest: > 1. An IPv6-only receiver wants to receive multicast content from > an IPv4-only source (6-4). > 2. An IPv4 receiver wants to join a multicast group in IPv4 > domain via an IPv6-only network (4-6-4). > =20 > Are there solutions for the unicast counterpart of these use cases? > Yes; various solutions including: > 1. 6-4: RFC6146 > 2. 4-6-4: RFC6333, RFC6346, ... > =20 > The latest version of the document is available at: > = https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-= 03. > =20 > Comments and suggestions are more than welcome. > =20 > Cheers, > Med=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kerlyn2001@gmail.com Tue Aug 14 08:49:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FB221F8667 for ; Tue, 14 Aug 2012 08:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJLWw7Daa7fD for ; Tue, 14 Aug 2012 08:49:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB3321F8647 for ; Tue, 14 Aug 2012 08:49:25 -0700 (PDT) Received: by lahm15 with SMTP id m15so325081lah.31 for ; Tue, 14 Aug 2012 08:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=neXON8ZBQe4BWMJ4PqPCE3BRKeiiy8LAUh9g3iD/7Qo=; b=un/UpcULvmJIZhlYSWkPsA/MKH2J4e1XgZKJgGjwihKM/bW6YTUFTC114rI/j37ojk glSqO8wmvDTXIvqK7+2nqI+4Tq4N1+ABhkyHPDJ3ui1LzuQ3HqMxDkmtnsgAusFjd7+6 eN4JNF6a8B0CfsVaHEmSi9e6Wo2lq8WRkpB9gZ9TIMhlgSOWbtinfkn1d4cmKgJ3WG+O bzkZ3iICI9l3jdcHTmcVncOZUxfxkZMufubpRYqTSZYOVynRnWM7TaXmH/omFHed6R+6 vZ8XJdGhYmRfcljZpNJhsDs7oaSjf3LwxfDzb7/EEEg0uwnHgHYHW1DMB7NWOHjEAZgp GKMw== MIME-Version: 1.0 Received: by 10.112.104.3 with SMTP id ga3mr8149150lbb.77.1344959364157; Tue, 14 Aug 2012 08:49:24 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.47.131 with HTTP; Tue, 14 Aug 2012 08:49:24 -0700 (PDT) In-Reply-To: <406302CF-A5B2-410C-985E-203D7173E1D6@employees.org> References: <406302CF-A5B2-410C-985E-203D7173E1D6@employees.org> Date: Tue, 14 Aug 2012 11:49:24 -0400 X-Google-Sender-Auth: mRKuBH2wUbB-asSrlqLShcRgcmo Message-ID: Subject: Re: Towards consensus on draft-ietf-6man-uri-zoneid From: Kerry Lynn To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=14dae9d7197623520004c73bc1a9 Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 15:49:31 -0000 --14dae9d7197623520004c73bc1a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 14, 2012 at 10:41 AM, Ole Tr=F8an wrote: > all, > > I fully accept that there are no perfect solution to this problem. > given that we are were we are... > it appears there is consensus building around Stuart's proposal. > > that entails: > - encode '%' as "%25" > - advocate that URI parsers are forgiving about accepting bare '%' > i.e. a '%' not followed by two valid hex characters is left untouched > - no update to RFC4007 > - no new delimiter > +1. My recollection was that the room rejected changes to RFC 4007 that involved including a new delimiter (thus taking a pure "cut and paste" solution off the table). I don't recall that clarifications to RFC 4007 to restrict the character set of zone identifiers was discussed at length or voted on. - interface names may themselves have to escaped (non-roman or [] > characters) > > It may be that restricting the character set of at this point may cause as many problems for existing tools like ping6 as adding a new delimiter; still, I'd like to hear some discussion on Brian's proposal to update RFC 4007 in conjunction with this draft. Also, the minutes should reflect that my thanks (and I suspect that I speak for others) also extend to Brian for taking on this task. My exact words were "... an illustration that no good deed goes unpunished". Regards, -K- please reply to the list if you support or disagree with the proposal _and_ > have additional arguments for discussion. > (there is no need to reply with "+1" or "-1" without arguments.) > > Best regards, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --14dae9d7197623520004c73bc1a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 14, 2012 at 10:41 AM, Ole Tr=F8an <otroan@employees.org= > wrote:
all,

I fully accept that there are no perfect solution to this problem.
given that we are were we are...
it appears there is consensus building around Stuart's proposal.

that entails:
=A0- encode '%' as "%25"
=A0- advocate that URI parsers are forgiving about accepting bare '%= 9;
=A0 =A0i.e. a '%' not followed by two valid hex characters is left = untouched
=A0- no update to RFC4007
=A0- no new delimiter

+1.
My recollection was that the room rejected changes to RFC 4007<= /div>
that involved including a new delimiter (thus taking a pure "= ;cut and
paste" solution off the table). =A0I don't recall that clarif= ications to RFC
4007 to restrict the character set of zone identi= fiers <zone_id> was
discussed at length or voted on.

=A0- interface names may them= selves have to escaped (non-roman or [] characters)

It may be that restricting the character set of <z= one_id> at this point
may cause as many problems for existing = tools like ping6 as adding
a new delimiter; still, I'd like t= o hear some discussion on Brian's
proposal to update RFC 4007 in conjunction with this draft.
=
Also, the minutes should reflect that my thanks (and I = suspect that I
speak for others) also extend to Brian for taking = on this task. =A0My exact
words were "... an illustration that no good deed goes unpunished= ".

Regards, -K-

please reply to the list if you support or disagree with the proposal _and_=
have additional arguments for discussion.
(there is no need to reply with "+1" or "-1" without ar= guments.)

Best regards,
Ole
--------------------------------------------------------------------=
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--14dae9d7197623520004c73bc1a9-- From fred@cisco.com Tue Aug 14 09:28:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D763F21F8738 for ; Tue, 14 Aug 2012 09:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWHjLlOzsgR5 for ; Tue, 14 Aug 2012 09:28:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 40C3B21F871E for ; Tue, 14 Aug 2012 09:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1948; q=dns/txt; s=iport; t=1344961693; x=1346171293; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=No7qR1ECx+0xcMHQh3p6hYAUlXK1QtSZY73S+8YLKuA=; b=GbPrJVkUPpHycu/KLkM+aODsrirn1l4e4FGzDKUzgSZJ1dNHQjQDkw58 AuGbbc8v+/SZAwgsNfMu5D655PIMuj9GUBPJVKr7AToVkBH3ixRnn2ge8 FpNUdSD/mgCSzWvZClanaNrMIkICumaWSIHC4l/WfN7YuYahgYZZsZ7qR Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANB7KlCtJXG9/2dsb2JhbAA/BroYgQeCIAEBAQMBEgFrCwIBCBA2MiUCBDWHZQaYN6B+iwUmhStgA5VLjiqBZoJf X-IronPort-AV: E=Sophos;i="4.77,766,1336348800"; d="scan'208";a="111516785" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 14 Aug 2012 16:28:12 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7EGSCjH006816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 14 Aug 2012 16:28:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 11:28:12 -0500 From: "Fred Baker (fred)" To: "ipv6@ietf.org 6man" Subject: Re: DAD question Thread-Topic: DAD question Thread-Index: AQHNehHJckLUSFUWY02BHbyxUsGbLZdZ00CA Date: Tue, 14 Aug 2012 16:28:12 +0000 Message-ID: References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> In-Reply-To: <201208141141.q7EBfiIe099885@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.220] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.003 x-tm-as-result: No--25.825400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:28:14 -0000 On Aug 14, 2012, at 4:41 AM, Francis Dupont wrote: > I remember (perhaps the first detected duplicate?) a very early occurrenc= e > before 1995 with a DEC box using a cloned full config. Same Decnet addres= s > so same MAC address so same IPv6 link-local address=85 Where I'm coming from in this is an expectation on my part that appears to = not be shared. If duplicate MAC addresses are unusual but reasonably common= (happen with some probability like .01% or whatever), there's a reasonable= expectation that there would be a work-around for the issue. The work-arou= nd, I suggest, would be to have the station use a privacy address instead o= f a MAC-based address when a duplicate MAC address is detected. I've said before that I find the fixation an MAC addresses strange; not all= devices have MAC addresses in the first place, and having built an EID fro= m a MAC address, there is no case in which we try to derive the MAC address= from it. Not all devices, believe it or not, have Ethernet or WiFi interfa= ces, and one with a WiFi and something else, such as your telephone, would = only use the WiFi MAC address for the EID on that interface. What do I mean= by "deriving the MAC from the EID"? There was a proposal in CLNS at one po= int (which failed for several reasons) to not need ES-IS and instead simply= use the MAC address of an interface as the host identifier part of an NSAP= - a router could pull it out and simply forward the datagram to the derive= d MAC address - and that model was used in XNS and IPX as well. But for the= same reasons that OSI didn't go with that model, we have not chosen to go = with that model in IPv6.=20 So the MAC address is at most a seed for building an EID, one of many, and = to my small mind if it doesn't result in a unique one, the obvious recovery= action is to pick another by a different algorithm. I gather nobody agrees with me.= From sarikaya2012@gmail.com Tue Aug 14 09:40:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B667D21F8771 for ; Tue, 14 Aug 2012 09:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfh5N-sbJVvD for ; Tue, 14 Aug 2012 09:40:35 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9606821F871E for ; Tue, 14 Aug 2012 09:40:23 -0700 (PDT) Received: by ggnh4 with SMTP id h4so749871ggn.31 for ; Tue, 14 Aug 2012 09:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BnCp7JlUhzvnZaW2HBbUISq/NT4FI2eQjxfpPoiLJ/k=; b=YDK7bbo+ZGEI1xDTmfhRiXHTWFfQbYRCNraXVkD4TBP64h5cPGYpxMnCUI2ZDAbMAY Qwwn+iQYBUNZddtMh7pXm8Y1yasE/qw4hd4lGn3H3mgPCcQQPoGVTdVgKbAgkATLzowe 7a0h7dsLV6NxKP2a9JroiuRhRU8GPkGux1gF+oKmcJ5sb+5tCuhUEncMYQ8qKop7TAWK Es9qzSFYQQRB3Ci4CfRDLTxo2ivb7nAOFKw5JEckX24mwNC7tGUIv54fhplcqOqo6ks8 k0IP4m2b8Kdo/l1orKyyYdJW/ddgSHjgB4n8KpHBQMIcNoPs7KpUPqVAak42XMqV1Akl ETEw== MIME-Version: 1.0 Received: by 10.43.45.200 with SMTP id ul8mr13444932icb.36.1344962421036; Tue, 14 Aug 2012 09:40:21 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Tue, 14 Aug 2012 09:40:20 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 14 Aug 2012 11:40:20 -0500 Message-ID: Subject: Re: draft-ietf-mboned-64-multicast-address-format From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" , "draft-ietf-mboned-64-multicast-address-format@tools.ietf.org" , Jacni Qin , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:40:35 -0000 On Tue, Aug 14, 2012 at 4:09 AM, wrote: > Dear all, > > I'm initiating this thread in the hope of understanding the > objections from the 6man WG and hopefully to make some progress for > this document. To initiate the discussion, below are provided some > preliminary Q/A: > > What is the scope of this document? > The document specifies an algorithmic translation of an IPv6 > multicast address to a corresponding IPv4 multicast address, and > vice versa. The document reserves two IPv6 multicast prefixes to > be used for that purpose. > > What are these reserved prefixes? > * ff3x:0:8000::/96 for SSM > * ffxx:8000::/20 for ASM > > Does this document update IPv6 addressing architecture? > No. > > Is there a unicast counterpart of this proposal? > Yes, RFC6052. > > What is the problem to be solved? > There are several use cases as detailed in [I-D.ietf-mboned-v4v6- > mcast-ps]. In particular, the following use cases are of > interest: > 1. An IPv6-only receiver wants to receive multicast content from > an IPv4-only source (6-4). > 2. An IPv4 receiver wants to join a multicast group in IPv4 > domain via an IPv6-only network (4-6-4). > > Are there solutions for the unicast counterpart of these use cases? > Yes; various solutions including: > 1. 6-4: RFC6146 > 2. 4-6-4: RFC6333, RFC6346, ... I don't understand why RFC 6333 is included here. If you take a look at http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-01 there is no need for this draft. Related to this is this statement in the abstract: This algorithmic translation can be used in both IPv4-IPv6 translation or encapsulation schemes. I suggest removing encapsulation from the above sentence. I have concerns on the way this draft justifies these new prefixes. I think the justification should be completely based on translation. If this basis is taken, the rest of the text will flow naturally. Regards, Behcet From stig@venaas.com Tue Aug 14 09:51:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821A021F8790 for ; Tue, 14 Aug 2012 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvW-hEvwaXe7 for ; Tue, 14 Aug 2012 09:51:49 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA6E21F8787 for ; Tue, 14 Aug 2012 09:51:47 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:68c6:e400:af0d:86da] (unknown [IPv6:2001:420:301:1004:68c6:e400:af0d:86da]) by ufisa.uninett.no (Postfix) with ESMTPSA id 594777FEC for ; Tue, 14 Aug 2012 18:51:44 +0200 (CEST) Message-ID: <502A821A.6080901@venaas.com> Date: Tue, 14 Aug 2012 09:51:38 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: draft-ietf-mboned-64-multicast-address-format References: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:51:49 -0000 On 8/14/2012 9:40 AM, Behcet Sarikaya wrote: > On Tue, Aug 14, 2012 at 4:09 AM, wrote: >> Dear all, >> >> I'm initiating this thread in the hope of understanding the >> objections from the 6man WG and hopefully to make some progress for >> this document. To initiate the discussion, below are provided some >> preliminary Q/A: >> >> What is the scope of this document? >> The document specifies an algorithmic translation of an IPv6 >> multicast address to a corresponding IPv4 multicast address, and >> vice versa. The document reserves two IPv6 multicast prefixes to >> be used for that purpose. >> >> What are these reserved prefixes? >> * ff3x:0:8000::/96 for SSM >> * ffxx:8000::/20 for ASM >> >> Does this document update IPv6 addressing architecture? >> No. >> >> Is there a unicast counterpart of this proposal? >> Yes, RFC6052. >> >> What is the problem to be solved? >> There are several use cases as detailed in [I-D.ietf-mboned-v4v6- >> mcast-ps]. In particular, the following use cases are of >> interest: >> 1. An IPv6-only receiver wants to receive multicast content from >> an IPv4-only source (6-4). >> 2. An IPv4 receiver wants to join a multicast group in IPv4 >> domain via an IPv6-only network (4-6-4). >> >> Are there solutions for the unicast counterpart of these use cases? >> Yes; various solutions including: >> 1. 6-4: RFC6146 >> 2. 4-6-4: RFC6333, RFC6346, ... > > > I don't understand why RFC 6333 is included here. > If you take a look at > http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-01 > there is no need for this draft. If I understand your draft correctly, it uses unicast for the encapsulation, then there is no need for this. But e.g. draft-ietf-softwire-dslite-multicast-02 needs it. If you are using multicast encapsulation (4 in 6), you need to know which group G or (S,G) to join at the tunnel egress point. And at the ingress, you need to interpret the IPv6 join you receive and extract the IPv4 address to know which IPv4 group is requested. For the latter part you could possibly encapsulate the joins, but I think that is not so good. Anyway, you need it for the first part. Encapsulation is very similar to translation. The only real difference I see, is that when you receive packets at the egress, you can just do decap, you don't need to figure out what the addresses in the new header should be. Stig > Related to this is this statement in the abstract: > > This > algorithmic translation can be used in both IPv4-IPv6 translation or > encapsulation schemes. > > I suggest removing encapsulation from the above sentence. > > I have concerns on the way this draft justifies these new prefixes. I > think the justification should be completely based on translation. If > this basis is taken, the rest of the text will flow naturally. > > Regards, > > Behcet > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From mcr+ietf@sandelman.ca Tue Aug 14 10:03:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1121F867D for ; Tue, 14 Aug 2012 10:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7hZ0r8CMbo3 for ; Tue, 14 Aug 2012 10:03:00 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 47BC721F8669 for ; Tue, 14 Aug 2012 10:02:57 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 843A920182 for ; Tue, 14 Aug 2012 13:16:04 -0400 (EDT) From: Michael Richardson To: "ipv6@ietf.org 6man" Subject: Re: DAD question In-Reply-To: References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 17:03:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "fred" =3D=3D fred > writes: fred> I've said before that I find the fixation an MAC addresses fred> strange; not all devices have MAC addresses in the first fred> place, and having built an EID from a MAC address, there is no But, enough devices have them that it's just not a concern.=20 The devices that don't tend not to do any kind of SLAAC. fred> So the MAC address is at most a seed for building an EID, one fred> of many, and to my small mind if it doesn't result in a unique fred> one, the obvious recovery action is to pick another by a fred> different algorithm. fred> I gather nobody agrees with me. I think that we agree with you. I think that most implementations of SLAAC were done prior to there being any other choice, and simply haven't been updated to do something different if DAD fails. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUCqEtoqHRg3pndX9AQLKdgQAn6Zo4lzpmCz0J/6KY7Cb7OfCBYkMr4xG 6VxRVXbCoP38V24H2OF7y5h3ih5XIwVVPe8+CoFFy3NVVTTRPar0yV42aGpIU+ey f5HZg8cdEjN+GKFy3VWZyZ9UAM1kJ2fW7QCZd5asm0/JiRncA/BDDcP4Ty8ft7kI yhL7AnwkjOQ= =waJZ -----END PGP SIGNATURE----- --=-=-=-- From simon.perreault@viagenie.ca Tue Aug 14 10:16:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A3821F85F0 for ; Tue, 14 Aug 2012 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA8xx3aycJBZ for ; Tue, 14 Aug 2012 10:16:17 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF3D21F85E4 for ; Tue, 14 Aug 2012 10:16:16 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:bd61:5240:a56f:1678]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CE471414AE for ; Tue, 14 Aug 2012 13:16:15 -0400 (EDT) Message-ID: <502A87DF.8080300@viagenie.ca> Date: Tue, 14 Aug 2012 13:16:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: DAD question References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 17:16:17 -0000 Le 2012-08-14 12:28, Fred Baker (fred) a écrit : > Where I'm coming from in this is an expectation on my part that > appears to not be shared. If duplicate MAC addresses are unusual but > reasonably common (happen with some probability like .01% or > whatever), there's a reasonable expectation that there would be a > work-around for the issue. The work-around, I suggest, would be to > have the station use a privacy address instead of a MAC-based address > when a duplicate MAC address is detected. Since privacy addresses are supposed to be configured alongside regular SLAAC addresses, there should be no need for an explicit fallback. Just enable both SLAAC and privacy simultaneously. If SLAAC fails, you still have privacy. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From albert.e.manfredi@boeing.com Tue Aug 14 11:58:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEFB21F87A4 for ; Tue, 14 Aug 2012 11:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5arEWdbLQTwO for ; Tue, 14 Aug 2012 11:58:46 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 64DBF21F879E for ; Tue, 14 Aug 2012 11:58:45 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q7EIwoHA016099 for ; Tue, 14 Aug 2012 11:58:51 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q7EIwoh8016090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2012 11:58:50 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q7EIwiee030541; Tue, 14 Aug 2012 11:58:44 -0700 Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q7EIwhH3030494 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 14 Aug 2012 11:58:43 -0700 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-05.mw.nos.boeing.com ([134.57.119.160]) with mapi; Tue, 14 Aug 2012 13:58:43 -0500 From: "Manfredi, Albert E" To: "Fred Baker (fred)" , "ipv6@ietf.org 6man" Date: Tue, 14 Aug 2012 13:58:41 -0500 Subject: RE: DAD question Thread-Topic: DAD question Thread-Index: AQHNehHJckLUSFUWY02BHbyxUsGbLZdZ00CA///VqJA= Message-ID: References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 18:58:47 -0000 > Fred Baker (fred) wrote: > The work-around, I suggest, would be to have the station use a privacy > address instead of a MAC-based address when a duplicate MAC address is > detected. Actually, I has the same thought when this subject came up. And DAD. > I gather nobody agrees with me. FWIW, I totally agree. Bert From fgont@si6networks.com Tue Aug 14 18:45:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAA521E80E1 for ; Tue, 14 Aug 2012 18:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 619DsSC+Rf7A for ; Tue, 14 Aug 2012 18:45:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9708321E80CD for ; Tue, 14 Aug 2012 18:45:56 -0700 (PDT) Received: from [186.134.26.60] (helo=[192.168.123.104]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T1SgB-0001p4-4h; Wed, 15 Aug 2012 03:45:51 +0200 Message-ID: <502AFF1F.6080904@si6networks.com> Date: Tue, 14 Aug 2012 22:45:03 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" Subject: Re: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-01.txt References: <20120810103916.17649.29017.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E10C4748@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E10C4748@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 01:45:57 -0000 Hi, Eric, Thanks so much for your feedback! -- Please find my comments in-line... On 08/14/2012 11:14 AM, Eric Vyncke (evyncke) wrote: > A couple of quick comments: - section 2: I would love to have data to > back the point of 'Many implementations fail to perform validation > checks on the received ICMPv6 error messages' (such as adding a > reference to your appendix) What data, specifically, would you expect? -- A list of vulnerable implementations or the like? You may want to try the icmp6 tool in the IPv6 toolkit to fire e.g. ICMPv6 PTB, and see that they are honored without e.g. checking the embedded TCP sequence number. - section 3: it would be nice to add some > text about the case where a packet is duplicated by the network > (could occur in rare circumstances) and one copy is fragmented (not > an atomic fragment) and the other copy is not (atomic fragment) > because of different path There's no fragmentation in routers, and hence this is not possible -- for instance, this is part of the rationale for RFC 5722. - section 3: not sure what is meant by 'FH > should (no uppercase?) be removed by the receiving host', This is the same as "performing fragmentation using only the atomic fragment"... the Next-Header field in the IPv6 fixed header should be changed to the value of the Next-Header in the FH, BTW. > on the > contrary, I would prefer to keep the FH in the packet (some apps may > need it) but immediately deliver the full packet to the upper layer - Do such stacks keep the FH for normal fragmented traffic? -- If so, how are each of the values (FOffset, etc.) selected? (Bottom-line: if this doesn't happen for normal fragmented traffic, I don't think we should make atomic fragments a special case). > section 3: it would be nice if some explanations were given why a > host receiving such an atomic fragment should not discard the > matching real fragments... Well, we don't really take a stance regarding what to do with the matching fragments. Performance-wise you may want to avoid searching through the queued fragments. Thoughts? > I tend to believe that upper layer (TCP > notably) will reject the second one if the sequence number match Not sure what you mean... > May I also suggest to integrate this I-D into the more generic > draft-gont-6man-predictable-fragment-id ? It will make the task of > implementers easier if both I-D are merged. I personally believe that both I-Ds are orthogonal. And also, procedurally-wise, at this point in time (past WGLC) we'll be better off progressing this one small document than trying to merge it with draft-gont-6man-predictable-fragment-id (which is not yet a wg item). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Wed Aug 15 00:05:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8560F21F85F7 for ; Wed, 15 Aug 2012 00:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.504 X-Spam-Level: X-Spam-Status: No, score=-101.504 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOcME4nhzlK2 for ; Wed, 15 Aug 2012 00:05:57 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D75A721F85F4 for ; Wed, 15 Aug 2012 00:05:56 -0700 (PDT) Received: by weyu54 with SMTP id u54so929442wey.31 for ; Wed, 15 Aug 2012 00:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ud1U8MZcozFVR1St+z4yzL2HED8hBgHZaKEAQoTmwFY=; b=DuOz3Ggj2vHBuJlM7Pj1mueG/3i7b4ORz+CEGdfkAODB3JswjGzqgjMynuK9t1Up+Q Y90rcbTq/oIjcliFTU0KlggFP3gqLOJUCoGnqsPaVMR9GBINEyPXrzB+GIxhJnlZcXTf H3rzaf3DCAjV1VqY8SI9Oxd0O5BIqTVVtezgE1r5AK4K+w5vpJZ1Cib2+aPAk3uYLSxj ecfSmDMfmguG2WhCzX3MiPju1og736GLTMzMZpfohBIan0lYjcIVk23lltfJiAdYGsGD 9IireDc1p0oxp0AorM99WQ00pnc7rEYvc8fn9icd0AjXEUNeOSsOQ2Rm+3Jsle1KlL8n CNdg== Received: by 10.180.107.103 with SMTP id hb7mr34697085wib.3.1345014356066; Wed, 15 Aug 2012 00:05:56 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-63.as13285.net. [2.102.218.63]) by mx.google.com with ESMTPS id el6sm26857441wib.8.2012.08.15.00.05.54 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 00:05:54 -0700 (PDT) Message-ID: <502B4A57.7080701@gmail.com> Date: Wed, 15 Aug 2012 08:05:59 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault Subject: Re: DAD question References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> <502A87DF.8080300@viagenie.ca> In-Reply-To: <502A87DF.8080300@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 07:05:57 -0000 On 14/08/2012 18:16, Simon Perreault wrote: > Le 2012-08-14 12:28, Fred Baker (fred) a =C3=A9crit : >> Where I'm coming from in this is an expectation on my part that >> appears to not be shared. If duplicate MAC addresses are unusual but >> reasonably common (happen with some probability like .01% or >> whatever), there's a reasonable expectation that there would be a >> work-around for the issue. The work-around, I suggest, would be to >> have the station use a privacy address instead of a MAC-based address >> when a duplicate MAC address is detected. >=20 > Since privacy addresses are supposed to be configured alongside regular= > SLAAC addresses, there should be no need for an explicit fallback. Just= > enable both SLAAC and privacy simultaneously. If SLAAC fails, you still= > have privacy. True, but you won't have connectivity on any network that uses MAC addres= s registration as a form of weak access control. Not that IPv6 can solve th= at problem, but it should be noted. Brian From daniel.crompton@gmail.com Wed Aug 15 03:40:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E205B21F86F9 for ; Wed, 15 Aug 2012 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3A6Ua6N5L3W for ; Wed, 15 Aug 2012 03:40:41 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF0FD21F86F4 for ; Wed, 15 Aug 2012 03:40:40 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1563022vcb.31 for ; Wed, 15 Aug 2012 03:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=2ejXdohxSuN5qoIaFKKHB8/asV91ZOQi2y9apvre9xk=; b=YCaRlZQVy7yxBGjzzasjbCLwGPAvC/eOLgv6hRbVQnNycZ2O+WqEFwrfUYDzLJhKSx tAwUAq6ZL3TwnJicEibkREQSc/V7gzAczK1h0mn2fsQP9xT2jSxD7M+/JvQyhbCFkwqM /pc0spsJUsaTYoTsJMoyL3paGmdqDuC9v0yOn86s1vmYulTEYKLadyS+I6ofZwUCncJS /8+bV+2WlmGc6Dx6NhTG2aZLr8+14hqa2q9ouAHg2RJ0BL7N8xvyf8l1cZqLNGguc2Md eclHLLAw+O3kkLIcdv3okfVVae9p9thrExw1pDZV/jm6xbl5gCrdDh3kDNSa4BNf/81l xJGQ== Received: by 10.52.17.75 with SMTP id m11mr10877777vdd.106.1345027231163; Wed, 15 Aug 2012 03:40:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.196.21 with HTTP; Wed, 15 Aug 2012 03:40:02 -0700 (PDT) In-Reply-To: <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> References: <36AA0AF8-95FD-4751-AE2E-A7A3D07038EB@cisco.com> <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> From: =?ISO-8859-1?Q?Dani=EBl_W=2E_Crompton?= Date: Wed, 15 Aug 2012 12:40:02 +0200 Message-ID: Subject: Re: DAD question To: "ipv6@ietf.org 6man" Content-Type: multipart/alternative; boundary=bcaec502d8de53a5d104c74b8ef4 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 10:40:42 -0000 --bcaec502d8de53a5d104c74b8ef4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11 August 2012 17:36, Bob Hinden wrote: <...snipped for brevity...> > For example, has any seen any actual duplicate MAC addresses? It would b= e > good to collect some data. Yes, I've seen this for several hardware manufactures. Most memorable were Sun boxes in which all of the 4 network interfaces shared the same MAC after unboxing. D. blaze your trail --=20 Dani=EBl W. Crompton http://specialbrands.net/ --bcaec502d8de53a5d104c74b8ef4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11 August 2012 17:36, Bob Hinden <bob.hinden@gmail.com> wrote:=A0
<...snipped for brevity...>=
For example, has any seen any actual duplicate MAC addresses? =A0It would b= e good to collect some data.

Yes, I've = seen this for several hardware manufactures. Most memorable were Sun boxes = in which all of the 4 network interfaces shared the same MAC after unboxing= .

D.

=A0
blaze your t= rail

--=A0
Dani=EBl W. Crompton=A0<daniel.crompton@gmail.com>
--bcaec502d8de53a5d104c74b8ef4-- From sthaug@nethelp.no Wed Aug 15 03:56:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1303021F86A4 for ; Wed, 15 Aug 2012 03:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I-HJkVeX11L for ; Wed, 15 Aug 2012 03:56:30 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 1951421F8648 for ; Wed, 15 Aug 2012 03:56:29 -0700 (PDT) Received: (qmail 72099 invoked from network); 15 Aug 2012 10:56:27 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Aug 2012 10:56:27 -0000 Date: Wed, 15 Aug 2012 12:56:27 +0200 (CEST) Message-Id: <20120815.125627.74680163.sthaug@nethelp.no> To: daniel.crompton@gmail.com Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: References: <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 10:56:31 -0000 > > For example, has any seen any actual duplicate MAC addresses? It would be > > good to collect some data. > > Yes, I've seen this for several hardware manufactures. Most memorable were > Sun boxes in which all of the 4 network interfaces shared the same MAC > after unboxing. Note that this is a perfectly valid configuration according to the Ethernet standards. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From fernando.gont.netbook.win@gmail.com Wed Aug 15 04:33:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C88E21F8555 for ; Wed, 15 Aug 2012 04:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31ZovCsVcNv7 for ; Wed, 15 Aug 2012 04:33:42 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 763B421F8554 for ; Wed, 15 Aug 2012 04:33:42 -0700 (PDT) Received: by yhq56 with SMTP id 56so1774264yhq.31 for ; Wed, 15 Aug 2012 04:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jy+BtIDKq5NzloDJZX9AfHi7xYSfguiDpvFReUfzxpo=; b=Z6y0wXDISBwuen1FKxk1/YxqJN6RUMKQUOPx8PnbB3Qn28UE54b7qqGjEzJr2vVz+F CyFXr2+qt/uV09gwKwH9iYTZZgbrEFw2sIUD81chyGbfs+zYVBL17Sz0bv/jrPCK+S7U Z7XZwDdRgHrH325kfJj7bPeTFXQM0OehxphPWcAZ04+SwnacvOQSQIIjDURw5xoq0IP6 k/6OmOU99RHy6VhoL6MZ8YjnG3xL7rPDKigJ6jfuwgPhpL80ei55f7DjFLRm35X3iyBd eR5GlQKOMPJu3DSv3eNZZngH/Sn6egLKmCf+v/lDSrul5Sl+sn+yyJ7GkMl8cszDweUB 7kMw== Received: by 10.236.115.138 with SMTP id e10mr18764487yhh.79.1345030418984; Wed, 15 Aug 2012 04:33:38 -0700 (PDT) Received: from [192.168.1.128] ([190.245.182.195]) by mx.google.com with ESMTPS id s1sm2168153yhi.5.2012.08.15.04.33.33 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 04:33:37 -0700 (PDT) Sender: Fernando Gont Message-ID: <502B88DC.3060300@gont.com.ar> Date: Wed, 15 Aug 2012 08:32:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: DAD question References: <409F28A1-7974-4524-893D-CEF349A96657@employees.org> <5FAE0128-DDE7-45C4-8632-F56EAA1BE362@gmail.com> <20120815.125627.74680163.sthaug@nethelp.no> In-Reply-To: <20120815.125627.74680163.sthaug@nethelp.no> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 11:33:43 -0000 On 08/15/2012 07:56 AM, sthaug@nethelp.no wrote: >> Yes, I've seen this for several hardware manufactures. Most memorable were >> Sun boxes in which all of the 4 network interfaces shared the same MAC >> after unboxing. > > Note that this is a perfectly valid configuration according to the > Ethernet standards. Just curious: were the MAC addresses "globally unique"? (me talking about the U/L bit in the MAC address). If they were, then I wonder how they could possibly be standards-compliant... or whether the U/L should have been named something else. :-) Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From sthaug@nethelp.no Wed Aug 15 04:38:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4E621F86A4 for ; Wed, 15 Aug 2012 04:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3modzaU-ZebM for ; Wed, 15 Aug 2012 04:38:12 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 1F56F21F856F for ; Wed, 15 Aug 2012 04:38:11 -0700 (PDT) Received: (qmail 73092 invoked from network); 15 Aug 2012 11:38:10 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Aug 2012 11:38:10 -0000 Date: Wed, 15 Aug 2012 13:38:10 +0200 (CEST) Message-Id: <20120815.133810.41706030.sthaug@nethelp.no> To: fernando@gont.com.ar Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: <502B88DC.3060300@gont.com.ar> References: <20120815.125627.74680163.sthaug@nethelp.no> <502B88DC.3060300@gont.com.ar> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 11:38:13 -0000 > > Note that this is a perfectly valid configuration according to the > > Ethernet standards. > > Just curious: were the MAC addresses "globally unique"? (me talking > about the U/L bit in the MAC address). Globally unique. The point here is that the Ethernet standards require a globally unique MAC address *per box*, not necessarily per interface. The "Sun way" of storing a MAC address in EEPROM and configuring all network cards with the same MAC address was perfectly compliant, just somewhat unusual. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From albert.e.manfredi@boeing.com Wed Aug 15 11:55:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4C721F874A for ; Wed, 15 Aug 2012 11:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBtNTDGhHw5Q for ; Wed, 15 Aug 2012 11:55:29 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id EAB6B21F8747 for ; Wed, 15 Aug 2012 11:55:28 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q7FItReM011958 for ; Wed, 15 Aug 2012 13:55:28 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q7FItQvp011952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Aug 2012 13:55:27 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q7FItQN8008366; Wed, 15 Aug 2012 11:55:26 -0700 Received: from XCH-MWHT-02.mw.nos.boeing.com (xch-mwht-02.mw.nos.boeing.com [134.57.113.20]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q7FItPws008345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 15 Aug 2012 11:55:26 -0700 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-02.mw.nos.boeing.com ([134.57.113.20]) with mapi; Wed, 15 Aug 2012 13:55:25 -0500 From: "Manfredi, Albert E" To: Brian E Carpenter Date: Wed, 15 Aug 2012 13:55:23 -0500 Subject: RE: DAD question Thread-Topic: DAD question Thread-Index: Ac16tHM2qdxnxNqsRn+XCw4IpvFSfAAYt2GA Message-ID: References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> <502A87DF.8080300@viagenie.ca> <502B4A57.7080701@gmail.com> In-Reply-To: <502B4A57.7080701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: No Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:55:29 -0000 QnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQoNCj4gT24gMTQvMDgvMjAxMiAxODoxNiwgU2ltb24g UGVycmVhdWx0IHdyb3RlOg0KDQo+ID4gU2luY2UgcHJpdmFjeSBhZGRyZXNzZXMgYXJlIHN1cHBv c2VkIHRvIGJlIGNvbmZpZ3VyZWQgYWxvbmdzaWRlDQo+IHJlZ3VsYXINCj4gPiBTTEFBQyBhZGRy ZXNzZXMsIHRoZXJlIHNob3VsZCBiZSBubyBuZWVkIGZvciBhbiBleHBsaWNpdCBmYWxsYmFjay4N Cj4gSnVzdA0KPiA+IGVuYWJsZSBib3RoIFNMQUFDIGFuZCBwcml2YWN5IHNpbXVsdGFuZW91c2x5 LiBJZiBTTEFBQyBmYWlscywgeW91DQo+IHN0aWxsDQo+ID4gaGF2ZSBwcml2YWN5Lg0KPiANCj4g VHJ1ZSwgYnV0IHlvdSB3b24ndCBoYXZlIGNvbm5lY3Rpdml0eSBvbiBhbnkgbmV0d29yayB0aGF0 IHVzZXMgTUFDDQo+IGFkZHJlc3MNCj4gcmVnaXN0cmF0aW9uIGFzIGEgZm9ybSBvZiB3ZWFrIGFj Y2VzcyBjb250cm9sLiBOb3QgdGhhdCBJUHY2IGNhbiBzb2x2ZQ0KPiB0aGF0DQo+IHByb2JsZW0s IGJ1dCBpdCBzaG91bGQgYmUgbm90ZWQuDQoNClVubGVzcyB0aGF0IE1BQyBhZGRyZXNzIGFjY2Vz cyBjb250cm9sIGlzIGRvbmUgYXQgTGF5ZXIgMiwgd2hpY2ggaXMgbm90IHVuY29tbW9uLg0KDQpC ZXJ0DQoNCg== From albert.e.manfredi@boeing.com Wed Aug 15 12:01:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD0521F8777 for ; Wed, 15 Aug 2012 12:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVxyMdylZAr4 for ; Wed, 15 Aug 2012 12:00:59 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id DC4EC21E80A8 for ; Wed, 15 Aug 2012 12:00:30 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q7FJ0UoQ018529 for ; Wed, 15 Aug 2012 14:00:30 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q7FJ0Swv018514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Aug 2012 14:00:29 -0500 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q7FJ0Sx9005977; Wed, 15 Aug 2012 12:00:28 -0700 Received: from XCH-MWHT-06.mw.nos.boeing.com (xch-mwht-06.mw.nos.boeing.com [134.57.113.166]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q7FJ0RYT005928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 15 Aug 2012 12:00:28 -0700 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-06.mw.nos.boeing.com ([134.57.113.166]) with mapi; Wed, 15 Aug 2012 14:00:27 -0500 From: "Manfredi, Albert E" To: "sthaug@nethelp.no" Date: Wed, 15 Aug 2012 14:00:26 -0500 Subject: RE: DAD question Thread-Topic: DAD question Thread-Index: Ac162nmH4Tr1flunQfqJ5qoyppaDuwAPToQg Message-ID: References: <20120815.125627.74680163.sthaug@nethelp.no> <502B88DC.3060300@gont.com.ar> <20120815.133810.41706030.sthaug@nethelp.no> In-Reply-To: <20120815.133810.41706030.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 19:01:00 -0000 sthaug@nethelp.no wrote: > Globally unique. The point here is that the Ethernet standards require > a globally unique MAC address *per box*, not necessarily per interface. > The "Sun way" of storing a MAC address in EEPROM and configuring all > network cards with the same MAC address was perfectly compliant, just > somewhat unusual. But that's not the whole story, right? The only way this can work is if one assumes that each interface of that bo= x is connected to a different IP subnet. I don't even think Ethernet rules = are what matters here. If the box should happen to be dual homed to the sam= e IP subnet, that Sun scheme doesn't work. (I suppose unless only one of th= e box's interface is active at any given time. Bert From joelja@bogus.com Wed Aug 15 12:18:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E8F21F8685 for ; Wed, 15 Aug 2012 12:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfP3vq3T+rBS for ; Wed, 15 Aug 2012 12:18:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6721F867F for ; Wed, 15 Aug 2012 12:18:22 -0700 (PDT) Received: from joels-MacBook-Air.local ([72.5.115.169]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q7FJIJA4024406 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 15 Aug 2012 19:18:20 GMT (envelope-from joelja@bogus.com) Message-ID: <502BF5F7.9070504@bogus.com> Date: Wed, 15 Aug 2012 12:18:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120731 Thunderbird/15.0 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: DAD question References: <20120815.125627.74680163.sthaug@nethelp.no> <502B88DC.3060300@gont.com.ar> <20120815.133810.41706030.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 15 Aug 2012 19:18:20 +0000 (UTC) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 19:18:22 -0000 On 8/15/12 12:00 PM, Manfredi, Albert E wrote: > sthaug@nethelp.no wrote: > >> Globally unique. The point here is that the Ethernet standards require >> a globally unique MAC address *per box*, not necessarily per interface. >> The "Sun way" of storing a MAC address in EEPROM and configuring all >> network cards with the same MAC address was perfectly compliant, just >> somewhat unusual. > But that's not the whole story, right? > > The only way this can work is if one assumes that each interface of that box is connected to a different IP subnet. I don't even think Ethernet rules are what matters here. If the box should happen to be dual homed to the same IP subnet, that Sun scheme doesn't work. (I suppose unless only one of the box's interface is active at any given time. To be clear the employment of that scheme predates existence of routers in in small network deployments. if you need more than one interface on the same subnet you adjust them accordingly. > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From sthaug@nethelp.no Wed Aug 15 12:25:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E2B21E803F for ; Wed, 15 Aug 2012 12:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xJ9qiLiIY+P for ; Wed, 15 Aug 2012 12:25:13 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id E310321E803C for ; Wed, 15 Aug 2012 12:25:12 -0700 (PDT) Received: (qmail 86286 invoked from network); 15 Aug 2012 19:25:10 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Aug 2012 19:25:10 -0000 Date: Wed, 15 Aug 2012 21:25:10 +0200 (CEST) Message-Id: <20120815.212510.74669626.sthaug@nethelp.no> To: albert.e.manfredi@boeing.com Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: References: <502B88DC.3060300@gont.com.ar> <20120815.133810.41706030.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 19:25:14 -0000 > > Globally unique. The point here is that the Ethernet standards require > > a globally unique MAC address *per box*, not necessarily per interface. > > The "Sun way" of storing a MAC address in EEPROM and configuring all > > network cards with the same MAC address was perfectly compliant, just > > somewhat unusual. > > But that's not the whole story, right? > > The only way this can work is if one assumes that each interface of that box is connected to a different IP subnet. I don't even think Ethernet rules are what matters here. If the box should happen to be dual homed to the same IP subnet, that Sun scheme doesn't work. (I suppose unless only one of the box's interface is active at any given time. Obviously. And I believe more modern Sun boxes actually have a MAC address per interface. All I'm saying is that there is nothing wrong, standards-wise, in having *one* globally unique MAC address per box. Having the same MAC address shared between two (or more) boxes *is* wrong, standards-wise. And unfortunately that's exactly what we're seeing in practice. Not often, but "often enough" that it may not be safe to ignore the possibility. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From albert.e.manfredi@boeing.com Wed Aug 15 12:37:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06A321F862B for ; Wed, 15 Aug 2012 12:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2on5Ozh34oFV for ; Wed, 15 Aug 2012 12:37:48 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id C556721F8622 for ; Wed, 15 Aug 2012 12:37:41 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q7FJbeqb014227 for ; Wed, 15 Aug 2012 14:37:40 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q7FJbdaY014218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Aug 2012 14:37:40 -0500 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q7FJbda8002343; Wed, 15 Aug 2012 12:37:39 -0700 Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q7FJbcXj002312 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 15 Aug 2012 12:37:39 -0700 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-03.mw.nos.boeing.com ([134.57.119.161]) with mapi; Wed, 15 Aug 2012 14:37:38 -0500 From: "Manfredi, Albert E" To: "sthaug@nethelp.no" Date: Wed, 15 Aug 2012 14:37:37 -0500 Subject: RE: DAD question Thread-Topic: DAD question Thread-Index: Ac17G7J9eq8EQtKBTUKYQEawHXTmBwAAPl2w Message-ID: References: <502B88DC.3060300@gont.com.ar> <20120815.133810.41706030.sthaug@nethelp.no> <20120815.212510.74669626.sthaug@nethelp.no> In-Reply-To: <20120815.212510.74669626.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 19:37:48 -0000 sthaug@nethelp.no wrote: > All I'm saying is that there is nothing wrong, > standards-wise, in having *one* globally unique MAC address per box. But I'm disagreeing. There is a lot wrong with having the same address on multiple ports of a bo= x, when those multiple ports share the same network. This is true both at l= ayer 2 and at layer 3, right? There are work-arounds, such as ensuring only one port is active, e.g. via = STP or whatever. The Sun scheme worked only under certain circumstances. It would violate st= andards in certain scenarios. > Having the same MAC address shared between two (or more) boxes *is* > wrong, standards-wise. And unfortunately that's exactly what we're > seeing in practice. Not often, but "often enough" that it may not be > safe to ignore the possibility. That's also true. Bert From sthaug@nethelp.no Wed Aug 15 12:44:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB67D21E803C for ; Wed, 15 Aug 2012 12:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+GDVFAnS792 for ; Wed, 15 Aug 2012 12:44:13 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 9591011E808A for ; Wed, 15 Aug 2012 12:44:12 -0700 (PDT) Received: (qmail 86541 invoked from network); 15 Aug 2012 19:44:10 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Aug 2012 19:44:10 -0000 Date: Wed, 15 Aug 2012 21:44:10 +0200 (CEST) Message-Id: <20120815.214410.41710461.sthaug@nethelp.no> To: albert.e.manfredi@boeing.com Subject: Re: DAD question From: sthaug@nethelp.no In-Reply-To: References: <20120815.212510.74669626.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 19:44:13 -0000 > > All I'm saying is that there is nothing wrong, > > standards-wise, in having *one* globally unique MAC address per box. > > But I'm disagreeing. > > There is a lot wrong with having the same address on multiple ports of a box, when those multiple ports share the same network. This is true both at layer 2 and at layer 3, right? For more info see for instance the following comp.dcom.lans.ethernet message from Rich Seifert: https://groups.google.com/group/comp.dcom.lans.ethernet/msg/dbe062f75538718d?hl=en&dmode=source&output=gplain Which is exactly why I said MAC addresses are not *ordinarily* assigned to CPU ports. Sun uses (used?) the model that I actually prefer, i.e., that the MAC address identifies the *station*, rather than the network interface. There is a discussion of these two models in "The Switch Book," excerpted here: "There are actually two philosophies for interpreting unicast addresses. One philosophy follows the premise that a unicast address identifies a device (e.g., a workstation or server), as opposed to a network interface installed within the device. Under this philosophy, when a device has multiple interfaces, it uses the same address on all of them. This approach was used in the original Xerox Network System (XNS) and most Sun Microsystems' products. The other philosophy, that an address uniquely identifies the interface rather than the device, sees more widespread application today, and is the model assumed in this book (even though the author has an affection and longing for the 'architectural purity' of the single address per device model). Using the address-per-interface philosophy, a device with multiple interfaces will have multiple unicast addresses assigned to it. Both philosophies are valid, in the sense that both can be made to work properly in a practical network. In neither case is there any ambiguity about the destination for a frame sent to a given unicast address." However, this is getting rather far away from the *practical* problem of DAD in the face of several boxes with the same MAC address on the same LAN segment. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From kauer@biplane.com.au Wed Aug 15 15:00:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3E421F85A8 for ; Wed, 15 Aug 2012 15:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zyCML5K84DL for ; Wed, 15 Aug 2012 15:00:37 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7621F85A7 for ; Wed, 15 Aug 2012 15:00:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAGobLFCWZX+7/2dsb2JhbAANOIYBtz8BAQEEI2YLGAICJgICVxmuM26TL4EhjSKCCoESA6Beh3Q Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.200]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 16 Aug 2012 07:30:28 +0930 Message-ID: <1345068027.2455.26.camel@karl> Subject: RE: DAD question From: Karl Auer To: ipv6@ietf.org Date: Thu, 16 Aug 2012 08:00:27 +1000 In-Reply-To: References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> <502A87DF.8080300@viagenie.ca> <502B4A57.7080701@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 22:00:38 -0000 On Wed, 2012-08-15 at 13:55 -0500, Manfredi, Albert E wrote: > > address registration as a form of weak access control. > Unless that MAC address access control is done at Layer 2, which is not uncommon. The two are different. One registers MACs at a central location and refuses service (eg DHCP) to unregistered MAC addresses. The hosts already have network access. The other checks at layer 2 whether they are permitted to access the network at all (e.g. 802.1x). Both systems have problems with duplicate MAC addresses. Not showstopper problems, but problems. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From mohamed.boucadair@orange.com Wed Aug 15 22:44:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B361F21F8615 for ; Wed, 15 Aug 2012 22:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxIOOvgken2H for ; Wed, 15 Aug 2012 22:44:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B7E3421F8610 for ; Wed, 15 Aug 2012 22:44:51 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3FAE432449F; Thu, 16 Aug 2012 07:44:50 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1E18F35C048; Thu, 16 Aug 2012 07:44:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 16 Aug 2012 07:44:32 +0200 From: To: Bob Hinden Date: Thu, 16 Aug 2012 07:44:31 +0200 Subject: RE: draft-ietf-mboned-64-multicast-address-format Thread-Topic: draft-ietf-mboned-64-multicast-address-format Thread-Index: Ac16MiqTqwsaD8ijS12i/s+CB98pPwBP4AVw Message-ID: <94C682931C08B048B7A8645303FDC9F36E4FC2D9DE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.16.22416 Cc: "ipv6@ietf.org" , "draft-ietf-mboned-64-multicast-address-format@tools.ietf.org" , Jacni Qin , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 05:44:52 -0000 Dear Bob, The main changes in -03 are as follows: * Abandon the M-bit idea to represent IPv4-embedded IPv6 multicast prefix * Explain the rationale for selecting a /96 (SSM) and /20 (ASM) * Reserve two prefixes to be used for the algorithmic translation of an IPv= 6 multicast address into an IPv4 one; and vice versa (1) ff3x:0:8000::/96 for SSM (2) ffxx:8000::/20 for ASM * The document does not update RFC4291; i.e., no change to the IPv6 address= ing architecture. =20 Cheers, Med >-----Message d'origine----- >De : Bob Hinden [mailto:bob.hinden@gmail.com]=20 >Envoy=E9 : mardi 14 ao=FBt 2012 17:33 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Bob Hinden; ipv6@ietf.org; Jacni Qin;=20 >draft-ietf-mboned-64-multicast-address-format@tools.ietf.org;=20 >Stig Venaas >Objet : Re: draft-ietf-mboned-64-multicast-address-format > >Med, > >The new draft appears to have many changes from the previous=20 >version. It would be helpful if you could describe the=20 >changes. This is usually done in the draft itself, but I=20 >didn't see it in -03. > >Thanks, >Bob > >On Aug 14, 2012, at 2:09 AM, =20 > wrote: > >> Dear all, >> =20 >> I'm initiating this thread in the hope of understanding the >> objections from the 6man WG and hopefully to make some progress for >> this document. To initiate the discussion, below are provided some >> preliminary Q/A: >> =20 >> What is the scope of this document? >> The document specifies an algorithmic translation of an IPv6 >> multicast address to a corresponding IPv4 multicast address, and >> vice versa. The document reserves two IPv6 multicast prefixes to >> be used for that purpose. >> =20 >> What are these reserved prefixes? >> * ff3x:0:8000::/96 for SSM >> * ffxx:8000::/20 for ASM >> =20 >> Does this document update IPv6 addressing architecture? >> No. >> =20 >> Is there a unicast counterpart of this proposal? >> Yes, RFC6052. >> =20 >> What is the problem to be solved? >> There are several use cases as detailed in [I-D.ietf-mboned-v4v6- >> mcast-ps]. In particular, the following use cases are of >> interest: >> 1. An IPv6-only receiver wants to receive multicast content from >> an IPv4-only source (6-4). >> 2. An IPv4 receiver wants to join a multicast group in IPv4 >> domain via an IPv6-only network (4-6-4). >> =20 >> Are there solutions for the unicast counterpart of these use cases? >> Yes; various solutions including: >> 1. 6-4: RFC6146 >> 2. 4-6-4: RFC6333, RFC6346, ... >> =20 >> The latest version of the document is available at: >>=20 >https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-addr ess-format-03. >> =20 >> Comments and suggestions are more than welcome. >> =20 >> Cheers, >> Med=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >= From mohamed.boucadair@orange.com Wed Aug 15 22:52:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D0721F8613 for ; Wed, 15 Aug 2012 22:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwtkNyFwy3W7 for ; Wed, 15 Aug 2012 22:52:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 896F221F8609 for ; Wed, 15 Aug 2012 22:52:08 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 42EEC22C1C2; Thu, 16 Aug 2012 07:52:07 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 20E2827C053; Thu, 16 Aug 2012 07:52:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 16 Aug 2012 07:51:49 +0200 From: To: "sarikaya@ieee.org" Date: Thu, 16 Aug 2012 07:51:48 +0200 Subject: RE: draft-ietf-mboned-64-multicast-address-format Thread-Topic: draft-ietf-mboned-64-multicast-address-format Thread-Index: Ac16O3ZKx1M6D6svRTiARdS6vs8wjwBNtkJg Message-ID: <94C682931C08B048B7A8645303FDC9F36E4FC2D9E0@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.16.22416 Cc: "ipv6@ietf.org" , "draft-ietf-mboned-64-multicast-address-format@tools.ietf.org" , Jacni Qin , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 05:52:12 -0000 Hi Behcet, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : mardi 14 ao=FBt 2012 18:40 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : ipv6@ietf.org; Jacni Qin;=20 >draft-ietf-mboned-64-multicast-address-format@tools.ietf.org;=20 >Stig Venaas >Objet : Re: draft-ietf-mboned-64-multicast-address-format > >On Tue, Aug 14, 2012 at 4:09 AM, wrote: >> Dear all, >> >> I'm initiating this thread in the hope of understanding the >> objections from the 6man WG and hopefully to make some progress for >> this document. To initiate the discussion, below are provided some >> preliminary Q/A: >> >> What is the scope of this document? >> The document specifies an algorithmic translation of an IPv6 >> multicast address to a corresponding IPv4 multicast address, and >> vice versa. The document reserves two IPv6 multicast prefixes to >> be used for that purpose. >> >> What are these reserved prefixes? >> * ff3x:0:8000::/96 for SSM >> * ffxx:8000::/20 for ASM >> >> Does this document update IPv6 addressing architecture? >> No. >> >> Is there a unicast counterpart of this proposal? >> Yes, RFC6052. >> >> What is the problem to be solved? >> There are several use cases as detailed in [I-D.ietf-mboned-v4v6- >> mcast-ps]. In particular, the following use cases are of >> interest: >> 1. An IPv6-only receiver wants to receive multicast content from >> an IPv4-only source (6-4). >> 2. An IPv4 receiver wants to join a multicast group in IPv4 >> domain via an IPv6-only network (4-6-4). >> >> Are there solutions for the unicast counterpart of these use cases? >> Yes; various solutions including: >> 1. 6-4: RFC6146 >> 2. 4-6-4: RFC6333, RFC6346, ... > > >I don't understand why RFC 6333 is included here. Med: RFC6333 is provided as an example of a unicast solution for the 4-6-4 = case. >If you take a look at >http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-01 >there is no need for this draft. Med: Yes, because you are using unicast not multicast capabilities between = the AFTR and the CPE. The solution adopted in softwire (http://datatracker.= ietf.org/doc/draft-ietf-softwire-dslite-multicast/) makes use of native mul= ticast capabilities to deliver IPv4 content over an IPv6 network. =20 > >Related to this is this statement in the abstract: > >This > algorithmic translation can be used in both IPv4-IPv6 translation or > encapsulation schemes. > >I suggest removing encapsulation from the above sentence. Med: The algorithmic translation is about address translation not the way p= ackets are constructed...which applies for both encap and translation. Spec= ific solutions design is out of scope.=20 > >I have concerns on the way this draft justifies these new prefixes. I >think the justification should be completely based on translation. If >this basis is taken, the rest of the text will flow naturally. > >Regards, > >Behcet >= From v6ops@globis.net Thu Aug 16 01:45:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BC21F8446 for ; Thu, 16 Aug 2012 01:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=4.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk-CXCgYFl9q for ; Thu, 16 Aug 2012 01:45:04 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6DF21F8476 for ; Thu, 16 Aug 2012 01:45:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4E8C28700AC; Thu, 16 Aug 2012 10:41:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA3UUGAl9NJM; Thu, 16 Aug 2012 10:40:47 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 65E20870049; Thu, 16 Aug 2012 10:40:47 +0200 (CEST) Message-ID: <502CB209.9000902@globis.net> Date: Thu, 16 Aug 2012 10:40:41 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: "Fred Baker (fred)" Subject: Re: Re: DAD question References: <201208141141.q7EBfiIe099885@givry.fdupont.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org 6man" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 08:45:14 -0000 I agree with you that there's a potential problem, and treating the MAC=20 address as one source of a seed is a potential solution. I think the discussion would benefit if there was a clear distinction=20 made between the BIA (burned in address aka native address that is=20 supposedly guaranteed to be unique by the delegated authority from the=20 IEEE to the OUI) and a locally administered address (g/l bit). DECnet IV used the latter, and hence avoiding duplicate MAC addresses=20 would depend on actions of local administrators. If admins don't do=20 their job correctly they will certainly not be unique, as the MAC=20 address is strongly tied to the DECnet IV area and node addresses. The=20 IPv6 stack would theoretically still have the former BIA available to=20 the drivers to either act as a seed or to use for SLAAC. Similar situation for Cisco HSRP, VRRP, HP HACMP etc. where there is a=20 deliberate duplication of MAC addresses, and some higher layer protocol=20 ensures only one is active at any one time. These machines still all=20 have a native MAC and IP address, as well as the floating virtual MAC=20 address and IP address. VM's would not generally have any unique globally assigned BIA, and only = have a locally administered MAC address generated by the local VM code,=20 plus perhaps access to one or more global physical NIC adapter=20 address(es) (shared with the host OS). I agree tight bidirectional coupling of L2 address & L3 address is=20 generally a bad idea (IPX over FDDI, Token Ring, + Ethernet), but it=20 could have avoided many ND resource depletion problems/ potential DoS=20 vectors. I have thought of posting something on VLSM/SLAAC, where the interface=20 identifier is simply an automatically assigned semi-random number like=20 the Appletalk node address in LLAP. That would potentially be beneficial = in avoiding duplicate MAC addresses, for encapsulations on systems=20 without a MAC address, and also in reducing resources required for ND=20 and any other processes that need to log/track non-existent nodes such=20 as firewalls and security scanners (there would be no hard link to /64=20 any more, and so admins would be free to assign longer prefix lengths).=20 VLSM worked quite well in IPv4. regards, RayH Fred Baker (fred) wrote: > On Aug 14, 2012, at 4:41 AM, Francis Dupont wrote: > >> I remember (perhaps the first detected duplicate?) a very early occurr= ence >> before 1995 with a DEC box using a cloned full config. Same Decnet add= ress >> so same MAC address so same IPv6 link-local address=85 > > Where I'm coming from in this is an expectation on my part that appears= to not be shared. If duplicate MAC addresses are unusual but reasonably = common (happen with some probability like .01% or whatever), there's a re= asonable expectation that there would be a work-around for the issue. The= work-around, I suggest, would be to have the station use a privacy addre= ss instead of a MAC-based address when a duplicate MAC address is detecte= d. > > I've said before that I find the fixation an MAC addresses strange; not= all devices have MAC addresses in the first place, and having built an E= ID from a MAC address, there is no case in which we try to derive the MAC= address from it. Not all devices, believe it or not, have Ethernet or Wi= Fi interfaces, and one with a WiFi and something else, such as your telep= hone, would only use the WiFi MAC address for the EID on that interface. = What do I mean by "deriving the MAC from the EID"? There was a proposal i= n CLNS at one point (which failed for several reasons) to not need ES-IS = and instead simply use the MAC address of an interface as the host identi= fier part of an NSAP - a router could pull it out and simply forward the = datagram to the derived MAC address - and that model was used in XNS and = IPX as well. But for the same reasons that OSI didn't go with that model,= we have not chosen to go with that model in IPv6. > > So the MAC address is at most a seed for building an EID, one of many, = and to my small mind if it doesn't result in a unique one, the obvious re= covery action is to pick another by a different algorithm. > > I gather nobody agrees with me. From internet-drafts@ietf.org Fri Aug 17 10:50:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A45521F845D; Fri, 17 Aug 2012 10:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO8Ex4RtNpHr; Fri, 17 Aug 2012 10:50:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D321F843E; Fri, 17 Aug 2012 10:50:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-lineid-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120817175022.7325.93209.idtracker@ietfa.amsl.com> Date: Fri, 17 Aug 2012 10:50:22 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:50:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : The Line Identification Destination Option Author(s) : Suresh Krishnan Alan Kavanagh Balazs Varga Sven Ooghe Erik Nordmark Filename : draft-ietf-6man-lineid-07.txt Pages : 17 Date : 2012-08-15 Abstract: In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the edge router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-lineid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-lineid-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-lineid-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Aug 17 14:40:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FC721E8063; Fri, 17 Aug 2012 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS46op026Hoz; Fri, 17 Aug 2012 14:40:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3357421E8055; Fri, 17 Aug 2012 14:40:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-lineid-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120817214024.17563.24914.idtracker@ietfa.amsl.com> Date: Fri, 17 Aug 2012 14:40:24 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:40:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : The Line Identification Destination Option Author(s) : Suresh Krishnan Alan Kavanagh Balazs Varga Sven Ooghe Erik Nordmark Filename : draft-ietf-6man-lineid-08.txt Pages : 17 Date : 2012-08-17 Abstract: In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the edge router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-lineid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-lineid-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-lineid-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Aug 21 08:27:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93D221F8754; Tue, 21 Aug 2012 08:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwd3aTqMlUlh; Tue, 21 Aug 2012 08:27:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075C921F845F; Tue, 21 Aug 2012 08:27:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (The Line Identification Destination Option) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120821152709.30359.96474.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 08:27:09 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:27:10 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'The Line Identification Destination Option' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the edge router. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Wed Aug 22 23:34:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C0811E80D5; Wed, 22 Aug 2012 23:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-DYwUGIChYK; Wed, 22 Aug 2012 23:34:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B7D11E80D2; Wed, 22 Aug 2012 23:34:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120823063446.1355.97879.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2012 23:34:46 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 06:34:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the IET= F. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-addr-select-opt-05.txt Pages : 11 Date : 2012-08-22 Abstract: RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 3484 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Fri Aug 24 01:50:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DC821F86F5 for ; Fri, 24 Aug 2012 01:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCzJHPNLBuQD for ; Fri, 24 Aug 2012 01:50:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B42A121F86F4 for ; Fri, 24 Aug 2012 01:50:48 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 98E3F2645AF; Fri, 24 Aug 2012 10:50:47 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6B936238055; Fri, 24 Aug 2012 10:50:47 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 24 Aug 2012 10:50:22 +0200 From: To: BOUCADAIR Mohamed OLNC/NAD/TIP , Bob Hinden Date: Fri, 24 Aug 2012 10:50:20 +0200 Subject: RE: draft-ietf-mboned-64-multicast-address-format Thread-Topic: draft-ietf-mboned-64-multicast-address-format Thread-Index: Ac16MiqTqwsaD8ijS12i/s+CB98pPwBP4AVwAZjO0TA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332A9BA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E4FC2D8C2@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4FC2D9DE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4FC2D9DE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.24.60412 Cc: "ipv6@ietf.org" , Jacni Qin , "draft-ietf-mboned-64-multicast-address-format@tools.ietf.org" , Stig Venaas X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 08:50:51 -0000 Dear all, FYI, a new version of this draft has been edited to take into account comme= nts received in mboned ML.=20 The main changes in -04 are as follows: o Indicate the draft update RFC3306 as suggested by T. Chown. We didn't added a note about rfc3956 as we are defining a bit reserved in 3306. o Because of the previous comment, the wording has been changed to indicate we are reserving a bit in the unicast prefix-based address not reserving a prefix for ASM. The rationale behind that is to encourage implementations check the value of the reserved bit rather than matching a prefix. o Clarify the meaning of "x" as requested by Behcet. o Behcet asked to reserve a /17 or /12 for ASM. We didn't considered that comment because we received in the past comments arguing that reserving /17 is a waste of multicast address space. This is documented in Section 3.1 of the draft. o Implemented some wording changes suggested by P. Koch. o Update the section with examples. A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-mboned-64-multicast-address-format-04. Cheers, Med=20 >-----Message d'origine----- >De : ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] De=20 >la part de mohamed.boucadair@orange.com >Envoy=E9 : jeudi 16 ao=FBt 2012 07:45 >=C0 : Bob Hinden >Cc : ipv6@ietf.org;=20 >draft-ietf-mboned-64-multicast-address-format@tools.ietf.org;=20 >Jacni Qin; Stig Venaas >Objet : RE: draft-ietf-mboned-64-multicast-address-format > >Dear Bob, > >The main changes in -03 are as follows: > >* Abandon the M-bit idea to represent IPv4-embedded IPv6=20 >multicast prefix > >* Explain the rationale for selecting a /96 (SSM) and /20 (ASM) > >* Reserve two prefixes to be used for the algorithmic=20 >translation of an IPv6 multicast address into an IPv4 one; and=20 >vice versa >(1) ff3x:0:8000::/96 for SSM >(2) ffxx:8000::/20 for ASM > >* The document does not update RFC4291; i.e., no change to the=20 >IPv6 addressing architecture. >=20 >Cheers, >Med > >>-----Message d'origine----- >>De : Bob Hinden [mailto:bob.hinden@gmail.com]=20 >>Envoy=E9 : mardi 14 ao=FBt 2012 17:33 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : Bob Hinden; ipv6@ietf.org; Jacni Qin;=20 >>draft-ietf-mboned-64-multicast-address-format@tools.ietf.org;=20 >>Stig Venaas >>Objet : Re: draft-ietf-mboned-64-multicast-address-format >> >>Med, >> >>The new draft appears to have many changes from the previous=20 >>version. It would be helpful if you could describe the=20 >>changes. This is usually done in the draft itself, but I=20 >>didn't see it in -03. >> >>Thanks, >>Bob >> >>On Aug 14, 2012, at 2:09 AM, =20 >> wrote: >> >>> Dear all, >>> =20 >>> I'm initiating this thread in the hope of understanding the >>> objections from the 6man WG and hopefully to make some progress for >>> this document. To initiate the discussion, below are provided some >>> preliminary Q/A: >>> =20 >>> What is the scope of this document? >>> The document specifies an algorithmic translation of an IPv6 >>> multicast address to a corresponding IPv4 multicast address, and >>> vice versa. The document reserves two IPv6 multicast prefixes to >>> be used for that purpose. >>> =20 >>> What are these reserved prefixes? >>> * ff3x:0:8000::/96 for SSM >>> * ffxx:8000::/20 for ASM >>> =20 >>> Does this document update IPv6 addressing architecture? >>> No. >>> =20 >>> Is there a unicast counterpart of this proposal? >>> Yes, RFC6052. >>> =20 >>> What is the problem to be solved? >>> There are several use cases as detailed in [I-D.ietf-mboned-v4v6- >>> mcast-ps]. In particular, the following use cases are of >>> interest: >>> 1. An IPv6-only receiver wants to receive multicast content from >>> an IPv4-only source (6-4). >>> 2. An IPv4 receiver wants to join a multicast group in IPv4 >>> domain via an IPv6-only network (4-6-4). >>> =20 >>> Are there solutions for the unicast counterpart of these use cases? >>> Yes; various solutions including: >>> 1. 6-4: RFC6146 >>> 2. 4-6-4: RFC6333, RFC6346, ... >>> =20 >>> The latest version of the document is available at: >>>=20 >>https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-addr >ess-format-03. >>> =20 >>> Comments and suggestions are more than welcome. >>> =20 >>> Cheers, >>> Med=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- >=