From alexandru.petrescu@gmail.com Mon Dec 2 03:09:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D97B1AE351 for ; Mon, 2 Dec 2013 03:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8ZdJWwpSRYw for ; Mon, 2 Dec 2013 03:09:40 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id DC4731AE343 for ; Mon, 2 Dec 2013 03:09:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB2B9aSv009682 for ; Mon, 2 Dec 2013 12:09:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6AF98201860 for ; Mon, 2 Dec 2013 12:09:41 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 590752016BB for ; Mon, 2 Dec 2013 12:09:41 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB2B9WK2015292 for ; Mon, 2 Dec 2013 12:09:36 +0100 Message-ID: <529C6A6D.6070307@gmail.com> Date: Mon, 02 Dec 2013 12:09:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] IPv6 over 802.11p - no modifications required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:09:43 -0000 draft-petrescu-ipv6-over-80211p-01.txt Hello participants to v6ops, Running IPv6 over 802.11p requires no modifications to the protocol: it runs just as IPv6 over Ethernet does - same 0x86DD Ethertype, same recommended minimal MTU, same formation of the Interface ID, ... However, in some operational environments, some tweaks may be necessary due to specificities of the link (e.g. OCB - outside the context of a BSS id): frequent Router Advertisements to support handover of high-speed vehicles through distanced Road-Side Units, and IP security messages because the link layer has no security features. This is what this draft describes: "Transmission of IPv6 Packets over IEEE 802.11p Networks" A. Petrescu, R. Kuntz, P. Pfister, N. Benamar http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01 What do you think? Alex From brian.e.carpenter@gmail.com Mon Dec 2 10:57:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CE61AD8CD for ; Mon, 2 Dec 2013 10:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2pHSud7R4Wh for ; Mon, 2 Dec 2013 10:57:53 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 636701AC404 for ; Mon, 2 Dec 2013 10:57:53 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so19529379pbb.4 for ; Mon, 02 Dec 2013 10:57:51 -0800 (PST) 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=sgr2I9RLybtUN05Q5XVW4DPc/z0+9do2eCKRWn5nvac=; b=US3EcTR/uobsmj3AhasN8IJGyAnVhomi96O4bXRAGD2GmO0Ry7RbyqVW9Ujr6MU0Yb MKQYbfCpnljmVQ3RiF2ftUgJ+KqHPdQJpaR0KO0iQ8OvAMwsuQcJkm1cZpyPP4uLYW5R s484B96U2uZVRLvtAZLuJBOk5T7b1zXFE+aRZSUrTQwRtLroqpUVBI0GQDwDyQv4RDi8 o4HgI0ZBv3E0uM7qdCdsWdspjOzV82S/9pB3cYqlILZNtWWSWUVvQd1xYMGAX5HwY2E6 W61d+4EZht7q+WS0A9kSJ8AVDN8P7vzEYPDcbvRTMxxszK0MPGxMiY/mLqGkLPE874bS u+CA== X-Received: by 10.67.1.101 with SMTP id bf5mr68614154pad.50.1386010671151; Mon, 02 Dec 2013 10:57:51 -0800 (PST) Received: from [192.168.178.20] (226.199.69.111.dynamic.snap.net.nz. [111.69.199.226]) by mx.google.com with ESMTPSA id xn12sm91409469pac.12.2013.12.02.10.57.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 10:57:50 -0800 (PST) Message-ID: <529CD82A.4010506@gmail.com> Date: Tue, 03 Dec 2013 07:57:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <529C6A6D.6070307@gmail.com> In-Reply-To: <529C6A6D.6070307@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 over 802.11p - no modifications required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:57:54 -0000 Hi 1. Surely this should be a 6man document, not v6ops? 2. "5.5. Stateless Autoconfiguration The Interface Identifier for an 802.11p interface is formed using the same rules as the Interface Identifier for an Ethernet interface; this is described in section 4 of [RFC2464]." Given the discussion of deprecating EUI-64, I think this should be: "The Interface Identifier for an 802.11p interface may be formed..." 3. I notice that you cite the RFC 2119 terminology but the draft doesn't actually use it. If you don't use it, please don't cite it. Regards Brian Carpenter On 03/12/2013 00:09, Alexandru Petrescu wrote: > draft-petrescu-ipv6-over-80211p-01.txt > > Hello participants to v6ops, > > Running IPv6 over 802.11p requires no modifications to the protocol: it > runs just as IPv6 over Ethernet does - same 0x86DD Ethertype, same > recommended minimal MTU, same formation of the Interface ID, ... > > However, in some operational environments, some tweaks may be necessary > due to specificities of the link (e.g. OCB - outside the context of a > BSS id): frequent Router Advertisements to support handover of > high-speed vehicles through distanced Road-Side Units, and IP security > messages because the link layer has no security features. > > This is what this draft describes: > > "Transmission of IPv6 Packets over IEEE 802.11p Networks" > A. Petrescu, R. Kuntz, P. Pfister, N. Benamar > http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01 > > What do you think? > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From hoskuld@hotmail.com Mon Dec 2 17:04:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FE21ADF92 for ; Mon, 2 Dec 2013 17:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No79k2aVfLjc for ; Mon, 2 Dec 2013 17:04:00 -0800 (PST) Received: from bay0-omc4-s25.bay0.hotmail.com (bay0-omc4-s25.bay0.hotmail.com [65.54.190.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0CECF1ADFEE for ; Mon, 2 Dec 2013 17:04:00 -0800 (PST) Received: from BAY173-W30 ([65.54.190.201]) by bay0-omc4-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 17:03:57 -0800 X-TMN: [fnTL+xm8yinaBSd9kZDYxfFZrJMYnpBPfS72bXI5qj8=] X-Originating-Email: [hoskuld@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_60b423e8-4ac2-40d0-bd4b-5d7862723d83_" From: Greg Daley To: Alexandru Petrescu , "v6ops@ietf.org" Date: Tue, 3 Dec 2013 12:03:57 +1100 Importance: Normal In-Reply-To: <529C6A6D.6070307@gmail.com> References: <529C6A6D.6070307@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2013 01:03:57.0657 (UTC) FILETIME=[8B63FC90:01CEEFC3] Subject: Re: [v6ops] IPv6 over 802.11p - no modifications required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 01:04:01 -0000 --_60b423e8-4ac2-40d0-bd4b-5d7862723d83_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alex=2C=20 =20 Increased RA rates were investigated for MIPv6=2C and this was not the pref= erred solution (though I submitted the text for the initial RFC). =20 Is it applicable to use Detecting Network Attachment procedures (RFC 6059) = instead of high rates of beacons? =20 (obviously I have a bias=2C but that was the evolution which brought about = the working group: MIPv6 o 802.11 w/beacons -> basic change detection suppo= rt in DNA) =20 Sincrerely=2C =20 Greg Daley +61 401 772 770 =20 > Date: Mon=2C 2 Dec 2013 12:09:33 +0100 > From: alexandru.petrescu@gmail.com > To: v6ops@ietf.org > Subject: [v6ops] IPv6 over 802.11p - no modifications required >=20 > draft-petrescu-ipv6-over-80211p-01.txt >=20 > Hello participants to v6ops=2C >=20 > Running IPv6 over 802.11p requires no modifications to the protocol: it > runs just as IPv6 over Ethernet does - same 0x86DD Ethertype=2C same > recommended minimal MTU=2C same formation of the Interface ID=2C ... >=20 > However=2C in some operational environments=2C some tweaks may be necessa= ry > due to specificities of the link (e.g. OCB - outside the context of a > BSS id): frequent Router Advertisements to support handover of > high-speed vehicles through distanced Road-Side Units=2C and IP security > messages because the link layer has no security features. >=20 > This is what this draft describes: >=20 > "Transmission of IPv6 Packets over IEEE 802.11p Networks" > A. Petrescu=2C R. Kuntz=2C P. Pfister=2C N. Benamar > http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01 >=20 > What do you think? >=20 > Alex >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --_60b423e8-4ac2-40d0-bd4b-5d7862723d83_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Alex=2C
 =3B
Incre= ased RA rates were investigated for MIPv6=2C and this was not the preferred= solution (though I submitted the text for the initial RFC).
 =3BIs it =3Bapplicable to use Detecting Network Attachment procedures (RF= C 6059) instead of high =3Brates of beacons?
 =3B
(obviously = I have a bias=2C =3Bbut that was the evolution which brought about the = working group: MIPv6 o 802.11 w/beacons ->=3B basic change detection supp= ort in DNA)
 =3B
Sincrerely=2C
 =3B
Greg Daley
+61 4= 01 772 770
 =3B
>=3B Date: Mon=2C 2 Dec 2013 12:09:33 +010= 0
>=3B From: alexandru.petrescu@gmail.com
>=3B To: v6ops@ietf.org=
>=3B Subject: [v6ops] IPv6 over 802.11p - no modifications required>=3B
>=3B draft-petrescu-ipv6-over-80211p-01.txt
>=3B
&g= t=3B Hello participants to v6ops=2C
>=3B
>=3B Running IPv6 over = 802.11p requires no modifications to the protocol: it
>=3B runs just a= s IPv6 over Ethernet does - same 0x86DD Ethertype=2C same
>=3B recomme= nded minimal MTU=2C same formation of the Interface ID=2C ...
>=3B >=3B However=2C in some operational environments=2C some tweaks may be n= ecessary
>=3B due to specificities of the link (e.g. OCB - outside the= context of a
>=3B BSS id): frequent Router Advertisements to support = handover of
>=3B high-speed vehicles through distanced Road-Side Units= =2C and IP security
>=3B messages because the link layer has no securi= ty features.
>=3B
>=3B This is what this draft describes:
>= =3B
>=3B "Transmission of IPv6 Packets over IEEE 802.11p Networks">=3B A. Petrescu=2C R. Kuntz=2C P. Pfister=2C N. Benamar
>=3B http:= //tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01
>=3B
>= =3B What do you think?
>=3B
>=3B Alex
>=3B
>=3B _____= __________________________________________
>=3B v6ops mailing list
= >=3B v6ops@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/v6ops=
= --_60b423e8-4ac2-40d0-bd4b-5d7862723d83_-- From sarikaya2012@gmail.com Tue Dec 3 09:38:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBD61A1F4A for ; Tue, 3 Dec 2013 09:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfAm9vkm2rfG for ; Tue, 3 Dec 2013 09:38:07 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AAE701A1F1A for ; Tue, 3 Dec 2013 09:38:06 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id ep20so9347483lab.34 for ; Tue, 03 Dec 2013 09:38:03 -0800 (PST) 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=N9UgW7gYUPMssth4tRkYjcutqKJADSsdqMyd0031EDE=; b=sycI7LC5EU7IVieWQVINLGOjD/1+shUi8j5FF27Vd1YPnurUOzKY/iE5oW6JS/NqGe iG3mhQ3IK+lFQfEz+msoZrhPGGa4yccQKwRAJdAMJZIT7Jg8BztaeEKreZm9WLKf6s48 jCLUX01t52a664dnzl4R9TAi6ltt/MbOL1fOV0Zx81bpY34b9e5HnDk1DzVUJqbiJ2UT dH7HlsF249+rTNkInNKnSe76FW7fMG3VJ4TlEcJl9T2tnkU6uwbF5aaPtKzkmzfAOnkf PXJjfQ603IKjJ5XoFrRThR6+yvR8tIoiV9arlV0NlSB0INOR5l5cxby486Yn25/hsaLr g4WQ== MIME-Version: 1.0 X-Received: by 10.152.87.13 with SMTP id t13mr86222laz.72.1386092283229; Tue, 03 Dec 2013 09:38:03 -0800 (PST) Received: by 10.114.217.129 with HTTP; Tue, 3 Dec 2013 09:38:03 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 11:38:03 -0600 Message-ID: From: Behcet Sarikaya To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=001a11c353e62afbb804eca4c230 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:38:09 -0000 --001a11c353e62afbb804eca4c230 Content-Type: text/plain; charset=ISO-8859-1 Hi Andrew, Thanks for writing this draft. It is interesting and useful. I have a few comments: 1. There is another draft, https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem what is the relation between these two drafts? 2. In Section 2.1, you consider Wi-Fi but not 3G/LTE. As you know, on 3G links, the standard requires SLAAC. 3. The document is missing a discussion on another aspect of this issue, i.e. RA options, such as in RFC 4191 and the corresponding DHCP option in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05. Adding this to your draft is recommended. 4. Lastly, your .txt document prints two pages for each page you have, I think there is some formatting issue. Regards, Behcet On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko wrote: > Hello all, > > Finally I managed to comb a little bit and finally submit the doc that > aims to compare RAs with DHCPv6 which emerged from the discussion on this > list a few weeks ago. > > I'll be very happy to hear any comments, suggestions, flames, etc. > > --a > > > p.s. The "realtime changes" repository is at: https://github.com/ayourtch/ > ra-dhcpv6, in case you want to send the feedback via a pull request :) > > ---------- Forwarded message ---------- > Date: Wed, 27 Nov 2013 04:52:14 -0800 > From: internet-drafts@ietf.org > To: Andrew Yourtchenko > Subject: New Version Notification for > draft-yourtchenko-ra-dhcpv6-comparison-00.txt > > > A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt > has been successfully submitted by Andrew Yourtchenko and posted to the > IETF repository. > > Filename: draft-yourtchenko-ra-dhcpv6-comparison > Revision: 00 > Title: A comparison between the DHCPv6 and RA based host > configuration > Creation date: 2013-11-27 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-yourtchenko-ra- > dhcpv6-comparison-00.txt > Status: http://datatracker.ietf.org/doc/draft-yourtchenko-ra- > dhcpv6-comparison > Htmlized: http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6- > comparison-00 > > > Abstract: > This document attempts to make a balanced comparison between the RA- > based and DHCPv6-based host configuration mechanisms. It compares > the two on different aspects, e.g: underlying media assumptions, > coordination, locality, etc. and highlights the strong and weak > sides of both protocols for each scenario. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c353e62afbb804eca4c230 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andre= w,

Thanks for writing this draft. It is interesting and useful= .

I have a few comments:

1. There is another draf= t, https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-p= roblem
what is the relation between these two drafts?
2. In Section= 2.1, you consider Wi-Fi but not 3G/LTE. As you know, on 3G links, the stan= dard requires SLAAC.
3. The document is missing a discussion on an= other aspect of this issue, i.e. RA options, such as in RFC 4191 and the co= rresponding DHCP option in http://tools.ietf.org/html/draft-ietf-mif-dhcp= v6-route-option-05.
Adding this to your draft is recommended.
4. Lastly, your .t= xt document prints two pages for each page you have, I think there is some = formatting issue.

Regards,

Behcet

On Wed, Nov 27, 2013 at 7:06 AM, Andrew You= rtchenko <ayourtch@cisco.com> wrote:
Hello all,

Finally I managed to comb a little bit and finally submit the doc that aims= to compare RAs with DHCPv6 which emerged from the discussion on this list = a few weeks ago.

I'll be very happy to hear any comments, suggestions, flames, etc.

--a


p.s. The "realtime changes" repository is at: https://github.com/ayourtc= h/ra-dhcpv6, in case you want to send the feedback via a pull re= quest :)

---------- Forwarded message ----------
Date: Wed, 27 Nov 2013 04:52:14 -0800
From: interne= t-drafts@ietf.org
To: Andrew Yourtchenko <ayourtch@cisco.com>
Subject: New Version Notification for
=A0 =A0 draft-yourtchenko-ra-dhcpv6-comparison-00.txt


A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt<= br> has been successfully submitted by Andrew Yourtchenko and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-yourtchenko-ra-dhcpv6-comparison
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 A comparison between the DHCPv6 and RA based hos= t configuration
Creation date: =A0 2013-11-27
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-compar= ison-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.iet= f.org/doc/draft-yourtchenko-ra-dhcpv6-comparison
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html= /draft-yourtchenko-ra-dhcpv6-comparison-00


Abstract:
=A0 =A0This document attempts to make a balanced comparison between the RA-=
=A0 =A0based and DHCPv6-based host configuration mechanisms. =A0It compares=
=A0 =A0the two on different aspects, e.g: underlying media assumptions,
=A0 =A0coordination, locality, etc. =A0and highlights the strong and weak =A0 =A0sides of both protocols for each scenario.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--001a11c353e62afbb804eca4c230-- From leo.liubing@huawei.com Tue Dec 3 17:36:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1F11ADFE1 for ; Tue, 3 Dec 2013 17:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyvWqHzi3OtZ for ; Tue, 3 Dec 2013 17:36:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C826B1ADFD8 for ; Tue, 3 Dec 2013 17:36:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ31367; Wed, 04 Dec 2013 01:36:22 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 01:35:35 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 01:36:21 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 09:36:14 +0800 From: "Liubing (Leo)" To: "sarikaya@ieee.org" , Andrew Yourtchenko Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO63G4kwQXArAis02nIypz2SIhVJpCP9WAgAEH5yA= Date: Wed, 4 Dec 2013 01:36:13 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D821E26@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D821E26nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 01:36:29 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D821E26nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Behcet 1. There is another draft, https://datatracker.ietf.org/doc/draft-ietf-v6op= s-dhcpv6-slaac-problem what is the relation between these two drafts? [Bing] As a co-author of the above mentioned draft, I think the scope of th= e two drafts is different. Draft-ietf-v6ops-dhcpv6-slaac-problem focuses on address configuration, whi= le Andrew's draft makes a more general comparison between ND and DHCPv6. As we know, there always be argument of things should be done through RA Op= tions or DHCPv6 options, so I think this draft is aiming to provide some gu= idance on this general issue. (Andrew, please correct me if I misunderstand your draft.) Regards, Bing --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D821E26nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Behcet=

 = ;

what is the relation between th= ese two drafts?

[Bing] As = a co-author of the above mentioned draft, I think the scope of the two draf= ts is different.

Draft-ietf= -v6ops-dhcpv6-slaac-problem focuses on address configuration, while Andrew&= #8217;s draft makes a more general comparison between ND and DHCPv6.

As we know= , there always be argument of things should be done through RA Options or D= HCPv6 options, so I think this draft is aiming to provide some guidance on this general issue.

 = ;

(Andrew, p= lease correct me if I misunderstand your draft.)

 = ;

Regards,

Bing<= /o:p>

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D821E26nkgeml506mbxchi_-- From ayourtch@cisco.com Wed Dec 4 01:45:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6C71AE230 for ; Wed, 4 Dec 2013 01:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXa4Kn5FREdV for ; Wed, 4 Dec 2013 01:45:53 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 946211AE22E for ; Wed, 4 Dec 2013 01:45:52 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB49jmK2026777 for ; Wed, 4 Dec 2013 10:45:48 +0100 (CET) Received: from [10.61.202.200] ([10.61.202.200]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB49jjkr006305; Wed, 4 Dec 2013 10:45:45 +0100 (CET) Date: Wed, 4 Dec 2013 10:45:47 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: sarikaya@ieee.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-655942458-1386150348=:35140" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:45:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-655942458-1386150348=:35140 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Hi Behcet, On Tue, 3 Dec 2013, Behcet Sarikaya wrote: > Hi Andrew, > > Thanks for writing this draft. It is interesting and useful. > > I have a few comments: > > 1. There is another draft, https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem > what is the relation between these two drafts? IIRC The draft I wrote came out of the discussion of the above draft (in fact I accidentally hijacked the thread there :) - there were the usual two strong opinions "this needs to be there" and "this does not need to be there", so I decided to try to write up a balanced overall comparison - especially that this type of question comes up a lot in many contexts outside the IETF. > 2. In Section 2.1, you consider Wi-Fi but not 3G/LTE. As you know, on 3G links, the standard requires SLAAC. Great catch! I added the new section to the "running head" version of the doc on the github. Thank you! > 3. The document is missing a discussion on another aspect of this issue, i.e. RA options, such as in RFC 4191 and the corresponding DHCP option in > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05. > Adding this to your draft is recommended. Could you suggest a one-paragraph wording for such a discussion ? Your comment triggered another idea in my head re options, but I would like to hear you first so I do not skew what you wanted to say - maybe they are different ideas. > 4. Lastly, your .txt document prints two pages for each page you have, I think there is some formatting issue. Indeed. Thanks! Weird, I just used the xml2rfc with the default settings, and the boilerplate came from template generator... Maybe I need to update it. I've created an issue onto the github repo for it, will take care of it. --a > > Regards, > > Behcet > > > On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko wrote: > Hello all, > > Finally I managed to comb a little bit and finally submit the doc that aims to compare RAs with DHCPv6 which emerged from the discussion on this list a few weeks ago. > > I'll be very happy to hear any comments, suggestions, flames, etc. > > --a > > > p.s. The "realtime changes" repository is at: https://github.com/ayourtch/ra-dhcpv6, in case you want to send the feedback via a pull request :) > > ---------- Forwarded message ---------- > Date: Wed, 27 Nov 2013 04:52:14 -0800 > From: internet-drafts@ietf.org > To: Andrew Yourtchenko > Subject: New Version Notification for >     draft-yourtchenko-ra-dhcpv6-comparison-00.txt > > > A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt > has been successfully submitted by Andrew Yourtchenko and posted to the > IETF repository. > > Filename:        draft-yourtchenko-ra-dhcpv6-comparison > Revision:        00 > Title:           A comparison between the DHCPv6 and RA based host configuration > Creation date:   2013-11-27 > Group:           Individual Submission > Number of pages: 12 > URL:             http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt > Status:          http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison > Htmlized:        http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 > > > Abstract: >    This document attempts to make a balanced comparison between the RA- >    based and DHCPv6-based host configuration mechanisms.  It compares >    the two on different aspects, e.g: underlying media assumptions, >    coordination, locality, etc.  and highlights the strong and weak >    sides of both protocols for each scenario. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > --0-655942458-1386150348=:35140-- From ayourtch@cisco.com Wed Dec 4 01:52:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8EC1AE1D3 for ; Wed, 4 Dec 2013 01:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYoJWxdiNVfA for ; Wed, 4 Dec 2013 01:52:40 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 609BC1AE0B9 for ; Wed, 4 Dec 2013 01:52:40 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB49qaot027404 for ; Wed, 4 Dec 2013 10:52:36 +0100 (CET) Received: from [10.61.202.200] ([10.61.202.200]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB49qXLt009520; Wed, 4 Dec 2013 10:52:33 +0100 (CET) Date: Wed, 4 Dec 2013 10:52:36 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D821E26@nkgeml506-mbx.china.huawei.com> Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D821E26@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-895937014-1386150757=:35140" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:52:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-895937014-1386150757=:35140 Content-Type: TEXT/PLAIN; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8BIT Hi Bing, On Wed, 4 Dec 2013, Liubing (Leo) wrote: > > Hi, Behcet > > > > 1. There is another draft, https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem > > what is the relation between these two drafts? > > [Bing] As a co-author of the above mentioned draft, I think the scope of the two drafts is different. > > Draft-ietf-v6ops-dhcpv6-slaac-problem focuses on address configuration, while Andrew¢s draft makes a more general comparison between ND and DHCPv6. > > As we know, there always be argument of things should be done through RA Options or DHCPv6 options, so I think this draft is aiming to provide some guidance on this general issue. > > (Andrew, please correct me if I misunderstand your draft.) I think yours is maybe an even laconic description than I've just sent in the other mail. Thank you! I've marked this down as an "issue" on github https://github.com/ayourtch/ra-dhcpv6/issues/3 , it's maybe a good thing to discuss the relationship between the two. --a > > > > Regards, > > Bing > > > > > --0-895937014-1386150757=:35140-- From alexandru.petrescu@gmail.com Wed Dec 4 04:40:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E588A1AE12C for ; Wed, 4 Dec 2013 04:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kekYDCinr04k for ; Wed, 4 Dec 2013 04:40:41 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 791801AE129 for ; Wed, 4 Dec 2013 04:40:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB4CebI8015723; Wed, 4 Dec 2013 13:40:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A01CB200EF1; Wed, 4 Dec 2013 13:40:44 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 93A11200E09; Wed, 4 Dec 2013 13:40:44 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB4CeWMb002053; Wed, 4 Dec 2013 13:40:36 +0100 Message-ID: <529F22C0.6080908@gmail.com> Date: Wed, 04 Dec 2013 13:40:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Brian E Carpenter References: <529C6A6D.6070307@gmail.com> <529CD82A.4010506@gmail.com> In-Reply-To: <529CD82A.4010506@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 over 802.11p - no modifications required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 12:40:45 -0000 Hi Brian, Thanks for the reply. Le 02/12/2013 19:57, Brian E Carpenter a écrit : > Hi > > 1. Surely this should be a 6man document, not v6ops? I would say yes, as it is a typical IPv6-over-foo document, and has no 6lowpan adaptation layer. (If we are to discuss it in 6man, among other things, we may discuss the necessity of describing the existing Ethernet Adaptation Layer.) The v6ops relevance may stem from its operational need in some deployments (IPv6 802.11p Road-Side Units, local regulation of frequency use, etc.) As you can see, we look for a path for this draft. > 2. "5.5. Stateless Autoconfiguration > > > The Interface Identifier for an 802.11p interface is formed using > the same rules as the Interface Identifier for an Ethernet > interface; this is described in section 4 of [RFC2464]." > > Given the discussion of deprecating EUI-64, I think this should be: > > "The Interface Identifier for an 802.11p interface may be formed..." I agree. Given that discussion, and if that 'deprecate' draft is adopted, we authors of this IPv6-over-11p draft need to change this to a MAY. > 3. I notice that you cite the RFC 2119 terminology but the draft > doesn't actually use it. If you don't use it, please don't cite it. Good point, I will have to remember this for future drafts as well. Alex > > Regards Brian Carpenter > > On 03/12/2013 00:09, Alexandru Petrescu wrote: >> draft-petrescu-ipv6-over-80211p-01.txt >> >> Hello participants to v6ops, >> >> Running IPv6 over 802.11p requires no modifications to the >> protocol: it runs just as IPv6 over Ethernet does - same 0x86DD >> Ethertype, same recommended minimal MTU, same formation of the >> Interface ID, ... >> >> However, in some operational environments, some tweaks may be >> necessary due to specificities of the link (e.g. OCB - outside the >> context of a BSS id): frequent Router Advertisements to support >> handover of high-speed vehicles through distanced Road-Side Units, >> and IP security messages because the link layer has no security >> features. >> >> This is what this draft describes: >> >> "Transmission of IPv6 Packets over IEEE 802.11p Networks" A. >> Petrescu, R. Kuntz, P. Pfister, N. Benamar >> http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01 >> >> What do you think? >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > From alexandru.petrescu@gmail.com Wed Dec 4 05:07:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902791AE128 for ; Wed, 4 Dec 2013 05:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1gcMAFVVNP9 for ; Wed, 4 Dec 2013 05:07:34 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5275D1AE0EC for ; Wed, 4 Dec 2013 05:07:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB4D7TUw026654; Wed, 4 Dec 2013 14:07:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 884232027E2; Wed, 4 Dec 2013 14:07:36 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 81510200DA9; Wed, 4 Dec 2013 14:07:36 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB4D7NDU021142; Wed, 4 Dec 2013 14:07:28 +0100 Message-ID: <529F290B.5070500@gmail.com> Date: Wed, 04 Dec 2013 14:07:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Greg Daley References: <529C6A6D.6070307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IPv6 over 802.11p - no modifications required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 13:07:37 -0000 Hi Greg, Thank you for the reply. Le 03/12/2013 02:03, Greg Daley a écrit : > Hi Alex, > > Increased RA rates were investigated for MIPv6, and this was not the > preferred solution (though I submitted the text for the initial > RFC). I do remember the activity, although not clearly about the preference. Yes, frequent RAs may noise slow/latent wireless links. In 802.11p they may lead to undesirable loss of urgent messages. That said, it may be a matter of finding the right ratio between RA periodicity, the link bandwidth and mandatory 0 probability of loss (for a given geometry of the RSU deployments and speed limitations). Currently, the Mobile IPv6 RFC6275 lowers the timer limits to e.g. MinRtrAdvInterval 0.03 seconds (as opposed to ND's 3 seconds RFC4861). However, that is a Mobile IPv6 specification, and it does not update the ND spec. Mobile IPv6 specs are not considered in RSUs of some 802.11p deployments. (although MIP specs are considered for the Router in the vehicle and in the HA). This is one of the reasons why we suggest this MIP low limit of MinRtrAdvInterval in this IPv6-over-80211p document. > Is it applicable to use Detecting Network Attachment procedures (RFC > 6059) instead of high rates of beacons? This is a good question. Is RFC6059 applicable to Router-to-Router communications (a vehicle holds a Router which connects to another Router sitting aside the road)? Second, it seems to me the DNA procedures are all preceded by a mandatory initial step of 'link-layer indication', or 'link up'. In 802.11 these indicators seem to be, by RFC4957, the receive of a link layer message (Ass'n Reply, or Auth Reply, or similar.) But 802.11p being a stripped-off version of 802.11, there is no Ass'n Reply, no Auth Reply, and the SSID is always the same (all 1s, 'wildcard BSSID'). This is the reason why I doubt about the applicability of DNA. I may be wrong though. For the IEEE 802.11p specifications see the web, or otherwise just ask. > (obviously I have a bias, but that was the evolution which brought > about the working group: MIPv6 o 802.11 w/beacons -> basic change > detection support in DNA) Does basic change detection work without a link up indicator? Alex > > Sincrerely, > > Greg Daley +61 401 772 770 > >> Date: Mon, 2 Dec 2013 12:09:33 +0100 From: >> alexandru.petrescu@gmail.com To: v6ops@ietf.org Subject: [v6ops] >> IPv6 over 802.11p - no modifications required >> >> draft-petrescu-ipv6-over-80211p-01.txt >> >> Hello participants to v6ops, >> >> Running IPv6 over 802.11p requires no modifications to the >> protocol: it runs just as IPv6 over Ethernet does - same 0x86DD >> Ethertype, same recommended minimal MTU, same formation of the >> Interface ID, ... >> >> However, in some operational environments, some tweaks may be >> necessary due to specificities of the link (e.g. OCB - outside the >> context of a BSS id): frequent Router Advertisements to support >> handover of high-speed vehicles through distanced Road-Side Units, >> and IP security messages because the link layer has no security >> features. >> >> This is what this draft describes: >> >> "Transmission of IPv6 Packets over IEEE 802.11p Networks" A. >> Petrescu, R. Kuntz, P. Pfister, N. Benamar >> http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01 >> >> What do you think? >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed Dec 4 05:45:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19E1AE262 for ; Wed, 4 Dec 2013 05:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x1J0s6Vc024 for ; Wed, 4 Dec 2013 05:45:29 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED61AE25F for ; Wed, 4 Dec 2013 05:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139; q=dns/txt; s=iport; t=1386164726; x=1387374326; h=date:from:message-id:to:subject:cc; bh=STNWv/mbBW4Fx/rJnrIDfwtbt3UrpI9G99Vm/y3yDtk=; b=OhySwZjw+qGkeCfXM0p9FIfs5ebuq4KABdQUPaZNM78VXVKnbCSBJpng Xoa4illyUNXonNcs0tJNIexQxJERSr9fH8GQ6RbEABx91UcOzIN9S88l3 JTfmhxp2hkwzL/ovKRGgRV1qHSrZPopAKS+AMREaLr2Bm7CWXT9YS9qYp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogKAPkwn1KrRDoH/2dsb2JhbABagwc4pncBkjoDBAKBIhZ0gyU8LQeIYg7BTBeOfh2EHQOJQpACkGODSg X-IronPort-AV: E=Sophos;i="4.93,824,1378857600"; d="scan'208";a="96918716" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 04 Dec 2013 13:45:24 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB4Dj1cv016056; Wed, 4 Dec 2013 13:45:11 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id rB4Dj1O12856; Wed, 4 Dec 2013 05:45:01 -0800 (PST) Date: Wed, 4 Dec 2013 05:45:01 -0800 (PST) From: Message-Id: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 13:45:34 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment. From jinmei.tatuya@gmail.com Wed Dec 4 09:58:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2592C1A1F7D for ; Wed, 4 Dec 2013 09:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.922 X-Spam-Level: * X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si19Wn8503CA for ; Wed, 4 Dec 2013 09:58:33 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 86A4A1A1EF9 for ; Wed, 4 Dec 2013 09:58:33 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id u57so9878791wes.32 for ; Wed, 04 Dec 2013 09:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7aI1w7CdGyWZzfhoA9KZ7SCUzNU5tCv11Njvhj7oP3g=; b=Cw91gwoTV1Z6/ik8fQNsimbyZX14yTdGpguJN/ftIplxa5vgfoyyJm6TWT5DYY76c3 2lbPSlCEFkFfwEZ0zamGr39Okyt8b8uXrxQLkVVflLkoA3eUp6mzFWM/7ravORnzaS57 aXbZldiNdLSpGWOy8ctIcB8Hb6j0gPo0jxdnYU+DkbeCc7XKPxEUSPfKmotix1lL1g2h ksnTfZ4Gbc5aaSjq35gQeapttP6V3VLSyj0AAS3LlwcnDQX+TNkV5krwZOKjVoHoZVpx y9P42HmKyPGjy6mxZpa/pIGlXoSXKWwV16Hz+wbWEax2XlaSM8pknpK1xwrDrh5LVc1v 1CRw== MIME-Version: 1.0 X-Received: by 10.194.6.161 with SMTP id c1mr596167wja.89.1386179910067; Wed, 04 Dec 2013 09:58:30 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Wed, 4 Dec 2013 09:58:29 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Dec 2013 09:58:29 -0800 X-Google-Sender-Auth: oDeWiWS2hBTovdeaA9KJ5VZ-PGk Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Andrew Yourtchenko Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:58:35 -0000 At Wed, 27 Nov 2013 14:06:03 +0100 (CET), Andrew Yourtchenko wrote: > Finally I managed to comb a little bit and finally submit the doc that > aims to compare RAs with DHCPv6 which emerged from the discussion on this > list a few weeks ago. > > I'll be very happy to hear any comments, suggestions, flames, etc. A minor point: this paragraph of Section 2.9 would need some editorial cleanup: On the other hand, it could be argued down to a choice of API: writing programs handling RA options like RDNSS is no harder than writing DHCPv6 client in terms of socket API. As long as the system supports RFC3542 you should be able to write a portable RA "client" pretty easily (meaning as easy/hard as writing some UDP client program). For example, FreeBSD's rtsold supports RDNSS and (AFAIK) only relies on the RFC3542 APIs. Also, since DHCP is trickier than other UDP applications in some points (it's more sensitive to which interface to use, and in some cases you need to make sure the source address is link-local, etc), it's quite likely that you'll need something like unusual APIs like RFC3542 or some non-portable system dependent interface to write a standard-compliant DHCP(v6) client. So, overall, I'd say the programming difficulty regarding UDP (DHCP) vs ICMP (RS/RA) is marginal. In that it contains some too-informal phrases like "AFAIK" or "I'd say". It looks like a mostly verbatim copy of some email message:-) -- JINMEI, Tatuya From sarikaya2012@gmail.com Wed Dec 4 12:50:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19911AE326 for ; Wed, 4 Dec 2013 12:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFunlPjxNrAt for ; Wed, 4 Dec 2013 12:50:26 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AF1AE2C4 for ; Wed, 4 Dec 2013 12:50:25 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id c11so9601501lbj.37 for ; Wed, 04 Dec 2013 12:50:21 -0800 (PST) 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=JvAlLPXcIwqAc1RbZj/jZ61xD1kjvOszuVrpBcS2nNE=; b=WTL0u26Opg05cTQt+bB9BtD+kn7y4fyRWnmneAZ+OIMCgUGHq19J93WvMN174sbood QN8SbokATJbMurS7y0bF8XU446+oaFs6FqhY9Pc2dzMF8ZIfaK78orlVybqiGFZ/LwUA 87PXcwGAUU51xtrv7rErbUe9TdQC/8mznZOsjCN33BytIygEof+6PZggxRkXvqjthgdr /mgJWuKF0hCVxQJrK+u2p6f7Jnwg5W/pnZrT5GGOwoQW7A3jWE41qB0vo2sUnFNngpOV vORnMiwcMsLrz0Mw6HIOMzDzhDpqXeDP8itZ6Gf3NqUj2ARW+tBR6IPbZcQQRQDMEZGB L83A== MIME-Version: 1.0 X-Received: by 10.152.234.170 with SMTP id uf10mr401020lac.43.1386190221723; Wed, 04 Dec 2013 12:50:21 -0800 (PST) Received: by 10.114.217.129 with HTTP; Wed, 4 Dec 2013 12:50:21 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Dec 2013 14:50:21 -0600 Message-ID: From: Behcet Sarikaya To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=001a1133ad0ec1ca9404ecbb8fee Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:50:29 -0000 --001a1133ad0ec1ca9404ecbb8fee Content-Type: text/plain; charset=ISO-8859-1 Hi Andrew, Please see inline. Regards, Behcet On Wed, Dec 4, 2013 at 3:45 AM, Andrew Yourtchenko wrote: > Hi Behcet, > > > On Tue, 3 Dec 2013, Behcet Sarikaya wrote: > > Hi Andrew, >> >> Thanks for writing this draft. It is interesting and useful. >> >> I have a few comments: >> >> 1. There is another draft, https://datatracker.ietf.org/ >> doc/draft-ietf-v6ops-dhcpv6-slaac-problem >> what is the relation between these two drafts? >> > > IIRC The draft I wrote came out of the discussion of the above draft (in > fact I accidentally hijacked the thread there :) - there were the usual two > strong opinions "this needs to be there" and "this does not need to be > there", so I decided to try to write up a balanced overall comparison - > especially that this type of question comes up a lot in many contexts > outside the IETF. > > > 2. In Section 2.1, you consider Wi-Fi but not 3G/LTE. As you know, on 3G >> links, the standard requires SLAAC. >> > > Great catch! I added the new section to the "running head" version of the > doc on the github. Thank you! > > > 3. The document is missing a discussion on another aspect of this issue, >> i.e. RA options, such as in RFC 4191 and the corresponding DHCP option in >> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05. >> Adding this to your draft is recommended. >> > > Could you suggest a one-paragraph wording for such a discussion ? Your > comment triggered another idea in my head re options, but I would like to > hear you first so I do not skew what you wanted to say - maybe they are > different ideas. > > Sure. Here is my text (two paragraphs instead of one :-)) Please feel free to add more, I believe other people, e.g. Brian Carpenter can also help. The issue is delivering routes to the hosts. RFC 4191 defines Router Advertisement extensions for communicating default router preferences and more- specific routes from routers to hosts. The draft on IPv6 RA Options for Next Hop Routes, draft-sarikaya-6man-rfc4191bis-00 proposes some new Router Advertisement options for configuring next hop routes on the mobile or fixed nodes. DHCP can also be used for delivering routes, as in draft-ietf-mif-dhcpv6-route-option-05. DHCPv6 Route Options can be defined basically to mimic the RA options defined in RFC 4191 as well as with some extensions such as the next hop address. DHCP approach claims the advantage of being applicable to configuring the routers, e.g. residential gateways (RG) or Customer Premises Equipment (CPE) as well as the hosts. > > 4. Lastly, your .txt document prints two pages for each page you have, I >> think there is some formatting issue. >> > > Indeed. Thanks! Weird, I just used the xml2rfc with the default settings, > and the boilerplate came from template generator... Maybe I need to update > it. I've created an issue onto the github repo for it, will take care of it. > > --a > > > >> Regards, >> >> Behcet >> >> >> On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko >> wrote: >> Hello all, >> >> Finally I managed to comb a little bit and finally submit the doc >> that aims to compare RAs with DHCPv6 which emerged from the discussion on >> this list a few weeks ago. >> >> I'll be very happy to hear any comments, suggestions, flames, etc. >> >> --a >> >> >> p.s. The "realtime changes" repository is at: >> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the >> feedback via a pull request :) >> >> ---------- Forwarded message ---------- >> Date: Wed, 27 Nov 2013 04:52:14 -0800 >> From: internet-drafts@ietf.org >> To: Andrew Yourtchenko >> Subject: New Version Notification for >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> >> >> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> has been successfully submitted by Andrew Yourtchenko and posted to >> the >> IETF repository. >> >> Filename: draft-yourtchenko-ra-dhcpv6-comparison >> Revision: 00 >> Title: A comparison between the DHCPv6 and RA based host >> configuration >> Creation date: 2013-11-27 >> Group: Individual Submission >> Number of pages: 12 >> URL: http://www.ietf.org/internet- >> drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> Status: http://datatracker.ietf.org/ >> doc/draft-yourtchenko-ra-dhcpv6-comparison >> Htmlized: http://tools.ietf.org/html/ >> draft-yourtchenko-ra-dhcpv6-comparison-00 >> >> >> Abstract: >> This document attempts to make a balanced comparison between the >> RA- >> based and DHCPv6-based host configuration mechanisms. It >> compares >> the two on different aspects, e.g: underlying media assumptions, >> coordination, locality, etc. and highlights the strong and weak >> sides of both protocols for each scenario. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> --001a1133ad0ec1ca9404ecbb8fee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Please see inline.<= br>
Regards,

Behcet


On Wed, Dec 4, 2013 at = 3:45 AM, Andrew Yourtchenko <ayourtch@cisco.com> wrote:
Hi Behcet,


On Tue, 3 Dec 2013, Behcet Sarikaya wrote:

Hi Andrew,

Thanks for writing this draft. It is interesting and useful.

I have a few comments:

1. There is another draft, https://datatracker.ie= tf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem
what is the relation between these two drafts?

IIRC The draft I wrote came out of the discussion of the above draft (in fa= ct I accidentally hijacked the thread there :) - there were the usual two s= trong opinions "this needs to be there" and "this does not n= eed to be there", so I decided to try to write up a balanced overall c= omparison - especially that this type of question comes up a lot in many co= ntexts outside the IETF.


2. In Section 2.1, you consider Wi-Fi but not 3G/LTE. As you know, on 3G li= nks, the standard requires SLAAC.

Great catch! I added the new section to the "running head" versio= n of the doc on the github. Thank you!


3. The document is missing a discussion on another aspect of this issue, i.= e. RA options, such as in RFC 4191 and the corresponding DHCP option in
http://tools.ietf.org/html/draft-ietf-mif-dhcpv6= -route-option-05.
Adding this to your draft is recommended.

Could you suggest a one-paragraph wording for such a discussion ? Your comm= ent triggered another idea in my head re options, but I would like to hear = you first so I do not skew what you wanted to say - maybe they are differen= t ideas.


Sure.
Here is my t= ext (two paragraphs instead of one :-)) Please feel free to add more, I bel= ieve other people, e.g. Brian Carpenter can also help.

The issue is = delivering routes to the hosts. RFC 4191 defines Router Advertisement exten= sions for communicating default router preferences and more-
=A0=A0 specific routes from routers to hosts. The draft on IPv6 RA Options = for=A0 Next Hop Routes, draft-sarikaya-6man-rfc4191bis-00 proposes some new= =A0 Router
=A0=A0 Advertisement options for configuring next hop routes = on the mobile
=A0=A0 or fixed nodes.
=A0=A0
DHCP can also be used for delivering = routes, as in draft-ietf-mif-dhcpv6-route-option-05. DHCPv6 Route Options c= an be defined basically to mimic the RA options defined in RFC 4191 as well= as with some extensions such as the next hop address. DHCP approach claims= the advantage of being applicable to configuring the routers, e.g. residen= tial
=A0=A0 gateways (RG) or Customer Premises Equipment (CPE) as well as the ho= sts.

4. Lastly, your .txt document prints two pages for each page you have, I th= ink there is some formatting issue.

Indeed. Thanks! Weird, I just used the xml2rfc with the default settings, a= nd the boilerplate came from template generator... Maybe I need to update i= t. I've created an issue onto the github repo for it, will take care of= it.

--a



Regards,

Behcet


On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko <ayourtch@cisco.com> wrote:
=A0 =A0 =A0 Hello all,

=A0 =A0 =A0 Finally I managed to comb a little bit and finally submit the d= oc that aims to compare RAs with DHCPv6 which emerged from the discussion o= n this list a few weeks ago.

=A0 =A0 =A0 I'll be very happy to hear any comments, suggestions, flame= s, etc.

=A0 =A0 =A0 --a


=A0 =A0 =A0 p.s. The "realtime changes" repository is at: https://github= .com/ayourtch/ra-dhcpv6, in case you want to send the feedback v= ia a pull request :)

=A0 =A0 =A0 ---------- Forwarded message ----------
=A0 =A0 =A0 Date: Wed, 27 Nov 2013 04:52:14 -0800
=A0 =A0 =A0 From: internet-drafts@ietf.org
=A0 =A0 =A0 To: Andrew Yourtchenko <ayourtch@cisco.com>
=A0 =A0 =A0 Subject: New Version Notification for
=A0 =A0 =A0 =A0 =A0 draft-yourtchenko-ra-dhcpv6-comparison-00.txt

=A0 =A0 =A0 A new version of I-D, draft-yourtchenko-ra-dhcpv6-compar= ison-00.txt
=A0 =A0 =A0 has been successfully submitted by Andrew Yourtchenko and poste= d to the
=A0 =A0 =A0 IETF repository.

=A0 =A0 =A0 Filename: =A0 =A0 =A0 =A0draft-yourtchenko-ra-dhcpv6-com= parison
=A0 =A0 =A0 Revision: =A0 =A0 =A0 =A000
=A0 =A0 =A0 Title: =A0 =A0 =A0 =A0 =A0 A comparison between the DHCPv6 and = RA based host configuration
=A0 =A0 =A0 Creation date: =A0 2013-11-27
=A0 =A0 =A0 Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
=A0 =A0 =A0 Number of pages: 12
=A0 =A0 =A0 URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-d= hcpv6-comparison-00.txt
=A0 =A0 =A0 Status: =A0 =A0 =A0 =A0 =A0http://dat= atracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison<= /a>
=A0 =A0 =A0 Htmlized: =A0 =A0 =A0 =A0http://tools.i= etf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00

=A0 =A0 =A0 Abstract:
=A0 =A0 =A0 =A0 =A0This document attempts to make a balanced comparison bet= ween the RA-
=A0 =A0 =A0 =A0 =A0based and DHCPv6-based host configuration mechanisms. = =A0It compares
=A0 =A0 =A0 =A0 =A0the two on different aspects, e.g: underlying media assu= mptions,
=A0 =A0 =A0 =A0 =A0coordination, locality, etc. =A0and highlights the stron= g and weak
=A0 =A0 =A0 =A0 =A0sides of both protocols for each scenario.




=A0 =A0 =A0 Please note that it may take a couple of minutes from the time = of submission
=A0 =A0 =A0 until the htmlized version and diff are available at tools.ietf.org.

=A0 =A0 =A0 The IETF Secretariat
=A0 =A0 =A0 _______________________________________________
=A0 =A0 =A0 v6ops mailing list
=A0 =A0 =A0 v6ops@ietf.= org
=A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/v6ops




--001a1133ad0ec1ca9404ecbb8fee-- From ayourtch@cisco.com Thu Dec 5 02:33:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3C91ADE86 for ; Thu, 5 Dec 2013 02:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BaSpW-PC6-x for ; Thu, 5 Dec 2013 02:33:23 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF961ADDD1 for ; Thu, 5 Dec 2013 02:33:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB5AXItE027898 for ; Thu, 5 Dec 2013 11:33:18 +0100 (CET) Received: from dhcp-10-149-4-110.cisco.com (dhcp-10-149-4-110.cisco.com [10.149.4.110]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB5AXHY8006182; Thu, 5 Dec 2013 11:33:18 +0100 (CET) Date: Thu, 5 Dec 2013 11:33:16 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1779957678-1386239598=:35140" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:33:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1779957678-1386239598=:35140 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed On Wed, 4 Dec 2013, $B?@L@C#:H(J wrote: > At Wed, 27 Nov 2013 14:06:03 +0100 (CET), > Andrew Yourtchenko wrote: > >> Finally I managed to comb a little bit and finally submit the doc that >> aims to compare RAs with DHCPv6 which emerged from the discussion on this >> list a few weeks ago. >> >> I'll be very happy to hear any comments, suggestions, flames, etc. > > A minor point: this paragraph of Section 2.9 would need some editorial > cleanup: > > On the other hand, it could be argued down to a choice of API: > writing programs handling RA options like RDNSS is no harder than > writing DHCPv6 client in terms of socket API. As long as the system > supports RFC3542 you should be able to write a portable RA "client" > pretty easily (meaning as easy/hard as writing some UDP client > program). For example, FreeBSD's rtsold supports RDNSS and (AFAIK) > only relies on the RFC3542 APIs. Also, since DHCP is trickier than > other UDP applications in some points (it's more sensitive to which > interface to use, and in some cases you need to make sure the source > address is link-local, etc), it's quite likely that you'll need > something like unusual APIs like RFC3542 or some non-portable system > dependent interface to write a standard-compliant DHCP(v6) client. > So, overall, I'd say the programming difficulty regarding UDP (DHCP) > vs ICMP (RS/RA) is marginal. > > In that it contains some too-informal phrases like "AFAIK" or "I'd > say". It looks like a mostly verbatim copy of some email message:-) You are absolutely correct - it's a mostly verbatim copy-paste that needs to be rephrased. I think I grabbed it from your conversation with Lorenzo :-) I've captured this into https://github.com/ayourtch/ra-dhcpv6/issues/4 Thanks a lot! :) --a > > -- > JINMEI, Tatuya > --0-1779957678-1386239598=:35140-- From alexandru.petrescu@gmail.com Thu Dec 5 05:15:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D291ADFD5 for ; Thu, 5 Dec 2013 05:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IwBAEg0CPSy for ; Thu, 5 Dec 2013 05:15:05 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B01221ADBCD for ; Thu, 5 Dec 2013 05:15:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB5DEwl6012715; Thu, 5 Dec 2013 14:14:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5FA29202C42; Thu, 5 Dec 2013 14:15:07 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 52AC72027EE; Thu, 5 Dec 2013 14:15:07 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB5DEsmc019663; Thu, 5 Dec 2013 14:14:58 +0100 Message-ID: <52A07C4E.5050004@gmail.com> Date: Thu, 05 Dec 2013 14:14:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andrew Yourtchenko References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:15:09 -0000 Thanks for the draft. IMHO it goes in a good direction to compare what can be done with DHCPv6 vs RA. I have some comments. > DHCPv6 needs at least 2 packets. RA is just one packet. This varies. It is mainly yes. But, an initial exchange is at minimum 4 DHCPv6 messages (including a costly discovery), whereas a DAD-less operation would be a single RA message (forgetting the initial MLD 'join'). > There is one additional reason for the DHCPv6 to be slower. One of the reasons DHCPv4/v6 may be slower lies in the discovery phase. Every discovery phase takes some time. Old DHCPv4 implementations take too much time, as do old WiFi 'scanning' operations (another discovery). Better implementations of the discovery phases take shorter time, yet they are extremely lengthy compared to what agreed numbers and multicast join/leave operations can achieve. > An RA-based protocol interaction may influence host's routing. A > DHCPv6-based interaction today can not influence the host's routing > - it was specifically denied any and all involvement into routing. [...] > FIXME: This section needs further debates, clarifications, and a > rewrite. Discussion welcome. There is an ongoing discussion in the DHC WG about this. Namely about routing at DHCP Relay during Prefix Delegation. Implementations consider seriously 'snooping' and adding routing table entries at Relay during DHCP operations. Standards e.g. BBF require a solution to this problem. There were several drafts and presentations during recent 2-3 years. Most recent draft is at draft-petrescu-relay-route-pd-problem-00.txt > Regarding RA for routing and DHCP for addressing, what people care > about is connectivity. What I need as an operator is a protocol > (preferably a single protocol because that is simpler) which will > enable my boxes to gain the connectivity they need. Whether you > call this routing or providing a default gateway, I don't much mind. > Look, there's too much ideology going on here. The IETF is being > dazzled by the sight of multiple lan segments and multiple egress > gateways without realising that these are the minority > configuration. All this effort is going into optimising ipv6 address > / lan autoconfiguration for these unusual scenarios without heeding > the sober reality that most people, service providers and enterprises > are only ever going to want to have a single defgw per lan segment, > and that by far the most common deployment scenario will be a single > lan segment per organisation. > > Wireless? My smartphone already has two radios and a physical > interface, connected to multiple providers. How exactly do you then > configure a "single defgw per lan segment" (without draft-troan- > homenet-sadr-01) > > I'm aware that this viewpoint will be regarded as retrograde, and > that a bunch of people on this list will probably sit there, rolling > their eyes and thinking: "yeah, and 640k was enough for everyone". > Just bear in mind that added complexity is not necessarily a good > thing. The support costs are high and the return on effort is > dubious at best. IOW, the IETF is optimising a corner case. This and later paragraphs read as a story I can understand but it would need reformulation to become less personal. Then... In the past we strived to build a table comparing the parameters which RA configures vs. the parameters which DHCP configures. The value was in finding which parameters are the exclusive domain of one or the other in current RFCs. For example, Prefix Delegation is only specified for DHCPv6 (not for RA), whereas the MTU parameter, and default router parameters (IP address, MAC address) are only for the RA (not for DHCP). Alex Le 27/11/2013 14:06, Andrew Yourtchenko a écrit : > Hello all, > > Finally I managed to comb a little bit and finally submit the doc > that aims to compare RAs with DHCPv6 which emerged from the > discussion on this list a few weeks ago. > > I'll be very happy to hear any comments, suggestions, flames, etc. > > --a > > > p.s. The "realtime changes" repository is at: > https://github.com/ayourtch/ra-dhcpv6, in case you want to send the > feedback via a pull request :) > > ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013 > 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko > Subject: New Version Notification for > draft-yourtchenko-ra-dhcpv6-comparison-00.txt > > > A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt > has been successfully submitted by Andrew Yourtchenko and posted to > the IETF repository. > > Filename: draft-yourtchenko-ra-dhcpv6-comparison Revision: > 00 Title: A comparison between the DHCPv6 and RA based host > configuration Creation date: 2013-11-27 Group: Individual > Submission Number of pages: 12 URL: > http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt > > > Status: > http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison > > Htmlized: > http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 > > > Abstract: This document attempts to make a balanced comparison > between the RA- based and DHCPv6-based host configuration mechanisms. > It compares the two on different aspects, e.g: underlying media > assumptions, coordination, locality, etc. and highlights the strong > and weak sides of both protocols for each scenario. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat _______________________________________________ > v6ops mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From volz@cisco.com Thu Dec 5 05:35:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEE01ADFB7 for ; Thu, 5 Dec 2013 05:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLkRfPwqvMlk for ; Thu, 5 Dec 2013 05:34:58 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 53F611ADFA3 for ; Thu, 5 Dec 2013 05:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6800; q=dns/txt; s=iport; t=1386250495; x=1387460095; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eTC9wSWRWqJJ0rMhBSUeiJZEKo7BLB9777XeRd+Cmw8=; b=FncpWi+tQYgICkv8zaH3vNPl6HRNdell8h7ybvOfzo61RPOFiKvPJsX6 Dd2WFBEpYpYE7nHbGJ066rZ1D6NJaTNnIMwpQp+U4nrx9lRf6MlQVZgr2 Ju5VKXY4I0RP0phyOerbmhbAZnhJQ3hhSu/Juzk7rEXCkVAR5qEtdJThQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFACeAoFKtJV2c/2dsb2JhbABTBoMHOLk/gRoWdIIlAQEBAwEBAQFiBwIIAQIFCwIBCBEDAQIBLiEGCx0IAgQOBQkSh1UDCQYNsg6IDQ2HGxeMb4FOEDMHBoMagRMDiQqNH4FrgTCLKoU5gWuBPg X-IronPort-AV: E=Sophos;i="4.93,833,1378857600"; d="scan'208";a="4537376" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 05 Dec 2013 13:34:54 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB5DYsUA014233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 13:34:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 07:34:54 -0600 From: "Bernie Volz (volz)" To: Alexandru Petrescu Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO63G69dtoxzvWTEqg/AfsgX9kzJpGBasA//+hABE= Date: Thu, 5 Dec 2013 13:34:53 +0000 Message-ID: <5262E1D6-8537-4C7D-A0D1-56FBC257AFC2@cisco.com> References: , <52A07C4E.5050004@gmail.com> In-Reply-To: <52A07C4E.5050004@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:35:00 -0000 This is an issue to clarify in this document (it may already be clear, but = that was one area I need to confirm in a reread) - it old compares address = assignment mechanisms, not prefix delegation. There's no alternative for pr= efix delegation, so nothing to compare with. The routing issues for PD are = a bit different than for addresses. - Bernie (from iPad) > On Dec 5, 2013, at 8:15 AM, "Alexandru Petrescu" wrote: >=20 > Thanks for the draft. IMHO it goes in a good direction to compare what > can be done with DHCPv6 vs RA. >=20 > I have some comments. >=20 >> DHCPv6 needs at least 2 packets. RA is just one packet. >=20 > This varies. It is mainly yes. >=20 > But, an initial exchange is at minimum 4 DHCPv6 messages (including a > costly discovery), whereas a DAD-less operation would be a single RA > message (forgetting the initial MLD 'join'). >=20 >> There is one additional reason for the DHCPv6 to be slower. >=20 > One of the reasons DHCPv4/v6 may be slower lies in the discovery phase. > Every discovery phase takes some time. Old DHCPv4 implementations take > too much time, as do old WiFi 'scanning' operations (another discovery). >=20 > Better implementations of the discovery phases take shorter time, yet > they are extremely lengthy compared to what agreed numbers and multicast > join/leave operations can achieve. >=20 >> An RA-based protocol interaction may influence host's routing. A >> DHCPv6-based interaction today can not influence the host's routing >> - it was specifically denied any and all involvement into routing. > [...] >> FIXME: This section needs further debates, clarifications, and a >> rewrite. Discussion welcome. >=20 > There is an ongoing discussion in the DHC WG about this. Namely about > routing at DHCP Relay during Prefix Delegation. Implementations > consider seriously 'snooping' and adding routing table entries at Relay > during DHCP operations. Standards e.g. BBF require a solution to this > problem. >=20 > There were several drafts and presentations during recent 2-3 years. > Most recent draft is at > draft-petrescu-relay-route-pd-problem-00.txt >=20 >> Regarding RA for routing and DHCP for addressing, what people care >> about is connectivity. What I need as an operator is a protocol >> (preferably a single protocol because that is simpler) which will >> enable my boxes to gain the connectivity they need. Whether you >> call this routing or providing a default gateway, I don't much mind. >> Look, there's too much ideology going on here. The IETF is being >> dazzled by the sight of multiple lan segments and multiple egress >> gateways without realising that these are the minority >> configuration. All this effort is going into optimising ipv6 address >> / lan autoconfiguration for these unusual scenarios without heeding >> the sober reality that most people, service providers and enterprises >> are only ever going to want to have a single defgw per lan segment, >> and that by far the most common deployment scenario will be a single >> lan segment per organisation. >>=20 >> Wireless? My smartphone already has two radios and a physical >> interface, connected to multiple providers. How exactly do you then >> configure a "single defgw per lan segment" (without draft-troan- >> homenet-sadr-01) >>=20 >> I'm aware that this viewpoint will be regarded as retrograde, and >> that a bunch of people on this list will probably sit there, rolling >> their eyes and thinking: "yeah, and 640k was enough for everyone". >> Just bear in mind that added complexity is not necessarily a good >> thing. The support costs are high and the return on effort is >> dubious at best. IOW, the IETF is optimising a corner case. >=20 > This and later paragraphs read as a story I can understand but it would > need reformulation to become less personal. >=20 > Then... >=20 > In the past we strived to build a table comparing the parameters which > RA configures vs. the parameters which DHCP configures. The value was > in finding which parameters are the exclusive domain of one or the other > in current RFCs. >=20 > For example, Prefix Delegation is only specified for DHCPv6 (not for > RA), whereas the MTU parameter, and default router parameters (IP > address, MAC address) are only for the RA (not for DHCP). >=20 > Alex >=20 > Le 27/11/2013 14:06, Andrew Yourtchenko a =E9crit : >> Hello all, >>=20 >> Finally I managed to comb a little bit and finally submit the doc >> that aims to compare RAs with DHCPv6 which emerged from the >> discussion on this list a few weeks ago. >>=20 >> I'll be very happy to hear any comments, suggestions, flames, etc. >>=20 >> --a >>=20 >>=20 >> p.s. The "realtime changes" repository is at: >> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the >> feedback via a pull request :) >>=20 >> ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013 >> 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko >> Subject: New Version Notification for >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>=20 >>=20 >> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> has been successfully submitted by Andrew Yourtchenko and posted to >> the IETF repository. >>=20 >> Filename: draft-yourtchenko-ra-dhcpv6-comparison Revision: >> 00 Title: A comparison between the DHCPv6 and RA based host >> configuration Creation date: 2013-11-27 Group: Individual >> Submission Number of pages: 12 URL: >> http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparis= on-00.txt >>=20 >>=20 >> Status: >> http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison > Htmlized: >> http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 >>=20 >>=20 >> Abstract: This document attempts to make a balanced comparison >> between the RA- based and DHCPv6-based host configuration mechanisms. >> It compares the two on different aspects, e.g: underlying media >> assumptions, coordination, locality, etc. and highlights the strong >> and weak sides of both protocols for each scenario. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >>=20 >> The IETF Secretariat _______________________________________________ >> v6ops mailing list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ayourtch@cisco.com Thu Dec 5 06:40:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978BD1AE028 for ; Thu, 5 Dec 2013 06:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTvgi3xO9VyW for ; Thu, 5 Dec 2013 06:40:08 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7992C1AE029 for ; Thu, 5 Dec 2013 06:40:08 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB5Ee4aR024753 for ; Thu, 5 Dec 2013 15:40:04 +0100 (CET) Received: from dhcp-10-149-4-110.cisco.com (dhcp-10-149-4-110.cisco.com [10.149.4.110]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB5Ee1vO012053; Thu, 5 Dec 2013 15:40:01 +0100 (CET) Date: Thu, 5 Dec 2013 15:40:01 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Alexandru Petrescu In-Reply-To: <52A07C4E.5050004@gmail.com> Message-ID: References: <52A07C4E.5050004@gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-960826059-1386254401=:58549" Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:40:11 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-960826059-1386254401=:58549 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Thanks a lot for the comments! inline... On Thu, 5 Dec 2013, Alexandru Petrescu wrote: > Thanks for the draft. IMHO it goes in a good direction to compare what > can be done with DHCPv6 vs RA. > > I have some comments. > >> DHCPv6 needs at least 2 packets. RA is just one packet. > > This varies. It is mainly yes. > > But, an initial exchange is at minimum 4 DHCPv6 messages (including a > costly discovery), What about Rapid Commit ? I was under impression there you can do the address assignment with just two messages. By "Costly" I assume you mean the "takes a long time because of the long inbuilt timeouts", as in the paragraph further below, I comment there. > whereas a DAD-less operation would be a single RA > message (forgetting the initial MLD 'join'). No, it would be an RS-RA sequence - *unless* either RA interval is every few seconds or the host is lucky enough to be connected just before the periodic RA is sent. (I > >> There is one additional reason for the DHCPv6 to be slower. > > One of the reasons DHCPv4/v6 may be slower lies in the discovery phase. > Every discovery phase takes some time. Old DHCPv4 implementations take > too much time, as do old WiFi 'scanning' operations (another discovery). > I found this snippet in RFC3315 interesting: "A client MUST collect Advertise messages for the first RT seconds, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 22.8). Any Advertise that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message that includes a Preference option with a preference value of 255, the client immediately begins a client- initiated message exchange (as described in section 18) by sending a Request message to the server from which the Advertise message was received. If the client receives an Advertise message that does not include a Preference option with a preference value of 255, the client continues to wait until the first RT elapses. If the first RT elapses and the client has received an Advertise message, the client SHOULD continue with a client-initiated message exchange by sending a Request message. " This means that in the case of a single-server, the discovery phase can be shortened by having the Preference of 255 - thus to be able to reduce the discovery process ? (I need to test if the hosts actually do this IRL, I suspect they do not). > Better implementations of the discovery phases take shorter time, yet > they are extremely lengthy compared to what agreed numbers and multicast > join/leave operations can achieve. ... "in the case of 0% packet loss". Add any packet loss and a single-packet scheme of RA becomes fragile and the worst case is dramatically worse than that of the DHCP. > >> An RA-based protocol interaction may influence host's routing. A >> DHCPv6-based interaction today can not influence the host's routing >> - it was specifically denied any and all involvement into routing. > [...] >> FIXME: This section needs further debates, clarifications, and a >> rewrite. Discussion welcome. > > There is an ongoing discussion in the DHC WG about this. Namely about > routing at DHCP Relay during Prefix Delegation. Implementations > consider seriously 'snooping' and adding routing table entries at Relay > during DHCP operations. Standards e.g. BBF require a solution to this > problem. > > There were several drafts and presentations during recent 2-3 years. > Most recent draft is at > draft-petrescu-relay-route-pd-problem-00.txt Yes, the Prefix Delegation is a completely special beast! I reread the RFC3633 - it does not even talk about DHCP servers - it talks about routers quite explicitly! I will try to reflect this somehow, created the https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks! > >> Regarding RA for routing and DHCP for addressing, what people care >> about is connectivity. What I need as an operator is a protocol >> (preferably a single protocol because that is simpler) which will >> enable my boxes to gain the connectivity they need. Whether you >> call this routing or providing a default gateway, I don't much mind. >> Look, there's too much ideology going on here. The IETF is being >> dazzled by the sight of multiple lan segments and multiple egress >> gateways without realising that these are the minority >> configuration. All this effort is going into optimising ipv6 address >> / lan autoconfiguration for these unusual scenarios without heeding >> the sober reality that most people, service providers and enterprises >> are only ever going to want to have a single defgw per lan segment, >> and that by far the most common deployment scenario will be a single >> lan segment per organisation. >> >> Wireless? My smartphone already has two radios and a physical >> interface, connected to multiple providers. How exactly do you then >> configure a "single defgw per lan segment" (without draft-troan- >> homenet-sadr-01) >> >> I'm aware that this viewpoint will be regarded as retrograde, and >> that a bunch of people on this list will probably sit there, rolling >> their eyes and thinking: "yeah, and 640k was enough for everyone". >> Just bear in mind that added complexity is not necessarily a good >> thing. The support costs are high and the return on effort is >> dubious at best. IOW, the IETF is optimising a corner case. > > This and later paragraphs read as a story I can understand but it would > need reformulation to become less personal. Yes, it is almost un-edited copy-paste from the emails, with ultra-light editing for the first pass. > > Then... > > In the past we strived to build a table comparing the parameters which > RA configures vs. the parameters which DHCP configures. The value was > in finding which parameters are the exclusive domain of one or the other > in current RFCs. > > For example, Prefix Delegation is only specified for DHCPv6 (not for > RA), whereas the MTU parameter, and default router parameters (IP > address, MAC address) are only for the RA (not for DHCP). Do you have somewhere this work ? I would be happy to incorporate it. Else, maybe it's worth to start rebuilding it in the appendix. I'll be tracking it in https://github.com/ayourtch/ra-dhcpv6/issues/6. --a > > Alex > > Le 27/11/2013 14:06, Andrew Yourtchenko a écrit : >> Hello all, >> >> Finally I managed to comb a little bit and finally submit the doc >> that aims to compare RAs with DHCPv6 which emerged from the >> discussion on this list a few weeks ago. >> >> I'll be very happy to hear any comments, suggestions, flames, etc. >> >> --a >> >> >> p.s. The "realtime changes" repository is at: >> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the >> feedback via a pull request :) >> >> ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013 >> 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko >> Subject: New Version Notification for >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> >> >> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> has been successfully submitted by Andrew Yourtchenko and posted to >> the IETF repository. >> >> Filename: draft-yourtchenko-ra-dhcpv6-comparison Revision: >> 00 Title: A comparison between the DHCPv6 and RA based host >> configuration Creation date: 2013-11-27 Group: Individual >> Submission Number of pages: 12 URL: >> http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> >> >> Status: >> http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison >> >> > Htmlized: >> http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 >> >> >> Abstract: This document attempts to make a balanced comparison >> between the RA- based and DHCPv6-based host configuration mechanisms. >> It compares the two on different aspects, e.g: underlying media >> assumptions, coordination, locality, etc. and highlights the strong >> and weak sides of both protocols for each scenario. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat _______________________________________________ >> v6ops mailing list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > --0-960826059-1386254401=:58549-- From otroan@employees.org Thu Dec 5 07:06:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD641AE059 for ; Thu, 5 Dec 2013 07:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lztyGuAws7x for ; Thu, 5 Dec 2013 07:06:16 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 98DB81AE038 for ; Thu, 5 Dec 2013 07:06:15 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-AV: E=Sophos;i="4.93,833,1378857600"; d="asc'?scan'208";a="1734559" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 05 Dec 2013 15:06:11 +0000 Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB5F65Lj000510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 15:06:05 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_2D8531AD-DE3D-4638-AC05-B6247EE9052F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <52A07C4E.5050004@gmail.com> Date: Thu, 5 Dec 2013 16:06:04 +0100 Message-Id: <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> References: <52A07C4E.5050004@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:06:17 -0000 --Apple-Mail=_2D8531AD-DE3D-4638-AC05-B6247EE9052F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alexandru, > For example, Prefix Delegation is only specified for DHCPv6 (not for > RA), whereas the MTU parameter, and default router parameters (IP > address, MAC address) are only for the RA (not for DHCP). that's because prefix delegation is a stateful operation that requires = per requesting router / client binding state. the general principle is "DHCPv6 can give different information to = different clients, RA give the same information to everyone." cheers, Ole --Apple-Mail=_2D8531AD-DE3D-4638-AC05-B6247EE9052F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSoJZcAAoJEFuJXizso86g1CIIAMSEX2zqgr1196LsMt5DZhIr yJbxsL4NluXc6g0naBKVNCrgciMPt5+o+UrsWCjMwvNkhLMUJQymcAD4493Y/YVM oTiTyB1Npc0ZR/qDTJfFW+qvedZvfJkEGqeDRJYSEJDy7CC2DPks06ZM6GAvcYhW n+ybePsc0e6a8bUPLkWJBe/mDz93JdAVFqT2tESP2Uj4zBOyMQlfwi2H2LLwdKyN ghqv/MfOUIxXjrw/AouuQorp9/co8IV4mOyzIAe+UOAsvDh8NomxN7gfcQKT4qOu 7S1Tcmv94fD6/1DdMcMSxvZZEfBIOWcmEmV/2ZYKTRzmyx6DvShQpe0ix2BGjzg= =+Jd8 -----END PGP SIGNATURE----- --Apple-Mail=_2D8531AD-DE3D-4638-AC05-B6247EE9052F-- From alexandru.petrescu@gmail.com Thu Dec 5 07:13:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0F91AE07F for ; Thu, 5 Dec 2013 07:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLpJyERe1Aew for ; Thu, 5 Dec 2013 07:13:48 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id EC9D61AE079 for ; Thu, 5 Dec 2013 07:13:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB5FDf5O028488; Thu, 5 Dec 2013 16:13:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CEF04202F9E; Thu, 5 Dec 2013 16:13:50 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C379A202EE7; Thu, 5 Dec 2013 16:13:50 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB5FDb30014885; Thu, 5 Dec 2013 16:13:41 +0100 Message-ID: <52A09821.20008@gmail.com> Date: Thu, 05 Dec 2013 16:13:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andrew Yourtchenko References: <52A07C4E.5050004@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:13:52 -0000 Le 05/12/2013 15:40, Andrew Yourtchenko a écrit : > Thanks a lot for the comments! > > inline... > > On Thu, 5 Dec 2013, Alexandru Petrescu wrote: > >> Thanks for the draft. IMHO it goes in a good direction to compare what >> can be done with DHCPv6 vs RA. >> >> I have some comments. >> >>> DHCPv6 needs at least 2 packets. RA is just one packet. >> >> This varies. It is mainly yes. >> >> But, an initial exchange is at minimum 4 DHCPv6 messages (including a >> costly discovery), > > What about Rapid Commit ? I was under impression there you can do the > address assignment with just two messages. I guess so yes. I doubt though it is the most used mode. Of course, one would just say Rapid Commit in this draft and it would be sufficient at this level. > By "Costly" I assume you mean the "takes a long time because of the long > inbuilt timeouts", as in the paragraph further below, I comment there. Yes. The longer the timeouts the higher the chances to discover something. The shorter the timeouts the higher the chances to miss some important server. >> whereas a DAD-less operation would be a single RA >> message (forgetting the initial MLD 'join'). > > No, it would be an RS-RA sequence - *unless* either RA interval is every > few seconds or the host is lucky enough to be connected just before the > periodic RA is sent. Yes, but there is an additional thing. The multicast RA works only if the Host has first subscribed to that group. And that needs an additional initial message from the Host to everybody else (the MLD 'join'). Basically, if the Host does not send that MLD message it will not receive the periodic multicast RA either. > (I > >> >>> There is one additional reason for the DHCPv6 to be slower. >> >> One of the reasons DHCPv4/v6 may be slower lies in the discovery phase. >> Every discovery phase takes some time. Old DHCPv4 implementations take >> too much time, as do old WiFi 'scanning' operations (another discovery). >> > > I found this snippet in RFC3315 interesting: > > "A client MUST collect Advertise messages for the first RT seconds, > unless it receives an Advertise message with a preference value of > 255. The preference value is carried in the Preference option > (section 22.8). Any Advertise that does not include a Preference > option is considered to have a preference value of 0. If the client > receives an Advertise message that includes a Preference option with > a preference value of 255, the client immediately begins a client- > initiated message exchange (as described in section 18) by sending a > Request message to the server from which the Advertise message was > received. If the client receives an Advertise message that does not > include a Preference option with a preference value of 255, the > client continues to wait until the first RT elapses. If the first RT > elapses and the client has received an Advertise message, the client > SHOULD continue with a client-initiated message exchange by sending a > Request message. > " > > This means that in the case of a single-server, the discovery phase can > be shortened by having the Preference of 255 - thus to be able to reduce > the discovery process ? (I need to test if the hosts actually do this > IRL, I suspect they do not). I guess yes, the paragraph above reflects a good way for DHCP behaviour to approach that ideal of a single exchange. >> Better implementations of the discovery phases take shorter time, yet >> they are extremely lengthy compared to what agreed numbers and multicast >> join/leave operations can achieve. > > ... "in the case of 0% packet loss". > > Add any packet loss and a single-packet scheme of RA becomes fragile and > the worst case is dramatically worse than that of the DHCP. I agree. >>> An RA-based protocol interaction may influence host's routing. A >>> DHCPv6-based interaction today can not influence the host's routing >>> - it was specifically denied any and all involvement into routing. >> [...] >>> FIXME: This section needs further debates, clarifications, and a >>> rewrite. Discussion welcome. >> >> There is an ongoing discussion in the DHC WG about this. Namely about >> routing at DHCP Relay during Prefix Delegation. Implementations >> consider seriously 'snooping' and adding routing table entries at Relay >> during DHCP operations. Standards e.g. BBF require a solution to this >> problem. >> >> There were several drafts and presentations during recent 2-3 years. >> Most recent draft is at >> draft-petrescu-relay-route-pd-problem-00.txt > > Yes, the Prefix Delegation is a completely special beast! I reread the > RFC3633 - it does not even talk about DHCP servers - it talks about > routers quite explicitly! I think the PD RFC defines a Delegating Router to be a DHCP Server, and then only talks DR. > I will try to reflect this somehow, created the > https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks! > >> >>> Regarding RA for routing and DHCP for addressing, what people care >>> about is connectivity. What I need as an operator is a protocol >>> (preferably a single protocol because that is simpler) which will >>> enable my boxes to gain the connectivity they need. Whether you >>> call this routing or providing a default gateway, I don't much mind. >>> Look, there's too much ideology going on here. The IETF is being >>> dazzled by the sight of multiple lan segments and multiple egress >>> gateways without realising that these are the minority >>> configuration. All this effort is going into optimising ipv6 address >>> / lan autoconfiguration for these unusual scenarios without heeding >>> the sober reality that most people, service providers and enterprises >>> are only ever going to want to have a single defgw per lan segment, >>> and that by far the most common deployment scenario will be a single >>> lan segment per organisation. >>> >>> Wireless? My smartphone already has two radios and a physical >>> interface, connected to multiple providers. How exactly do you then >>> configure a "single defgw per lan segment" (without draft-troan- >>> homenet-sadr-01) >>> >>> I'm aware that this viewpoint will be regarded as retrograde, and >>> that a bunch of people on this list will probably sit there, rolling >>> their eyes and thinking: "yeah, and 640k was enough for everyone". >>> Just bear in mind that added complexity is not necessarily a good >>> thing. The support costs are high and the return on effort is >>> dubious at best. IOW, the IETF is optimising a corner case. >> >> This and later paragraphs read as a story I can understand but it would >> need reformulation to become less personal. > > Yes, it is almost un-edited copy-paste from the emails, with ultra-light > editing for the first pass. > >> >> Then... >> >> In the past we strived to build a table comparing the parameters which >> RA configures vs. the parameters which DHCP configures. The value was >> in finding which parameters are the exclusive domain of one or the other >> in current RFCs. >> >> For example, Prefix Delegation is only specified for DHCPv6 (not for >> RA), whereas the MTU parameter, and default router parameters (IP >> address, MAC address) are only for the RA (not for DHCP). > > Do you have somewhere this work ? I would be happy to incorporate it. > Else, maybe it's worth to start rebuilding it in the appendix. There is this paragraph only in draft-mouton-mif-dhcpv6-drlo-02 > In addition to the default router address, lifetime and link-layer > address, the neighbor discovery mechanism also provides MTU, hop > limit, reachable time, retransmission timer[...] But I would very well see a table like this: | Configured by | +-------------+-------------+ Parameter on Host | DHCP | RA | -------------------+-------------+-------------+ Default Router IP | | X | -------------------+-------------+-------------+ Default Router MAC | | X | -------------------+-------------+-------------+ Global Address | X | X (w/ other)| -------------------+-------------+-------------+ Delegated Prefix | X | | -------------------+-------------+-------------+ Link MTU | | X | -------------------+-------------+-------------+ Hop Limit | | X | -------------------+-------------+-------------+ Link's reachable | | X | time, retr timer | | | -------------------+-------------+-------------+ DNS Resolver | X | X | -------------------+-------------+-------------+ Alex > > I'll be tracking it in https://github.com/ayourtch/ra-dhcpv6/issues/6. > > --a > >> >> Alex >> >> Le 27/11/2013 14:06, Andrew Yourtchenko a écrit : >>> Hello all, >>> >>> Finally I managed to comb a little bit and finally submit the doc >>> that aims to compare RAs with DHCPv6 which emerged from the >>> discussion on this list a few weeks ago. >>> >>> I'll be very happy to hear any comments, suggestions, flames, etc. >>> >>> --a >>> >>> >>> p.s. The "realtime changes" repository is at: >>> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the >>> feedback via a pull request :) >>> >>> ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013 >>> 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko >>> Subject: New Version Notification for >>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>> >>> >>> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>> has been successfully submitted by Andrew Yourtchenko and posted to >>> the IETF repository. >>> >>> Filename: draft-yourtchenko-ra-dhcpv6-comparison Revision: >>> 00 Title: A comparison between the DHCPv6 and RA based host >>> configuration Creation date: 2013-11-27 Group: Individual >>> Submission Number of pages: 12 URL: >>> http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>> >>> >>> >>> Status: >>> http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison >>> >>> >> Htmlized: >>> http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 >>> >>> >>> Abstract: This document attempts to make a balanced comparison >>> between the RA- based and DHCPv6-based host configuration mechanisms. >>> It compares the two on different aspects, e.g: underlying media >>> assumptions, coordination, locality, etc. and highlights the strong >>> and weak sides of both protocols for each scenario. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> The IETF Secretariat _______________________________________________ >>> v6ops mailing list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> From alexandru.petrescu@gmail.com Thu Dec 5 07:19:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C481AE0B1 for ; Thu, 5 Dec 2013 07:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGiGKyy4-3I2 for ; Thu, 5 Dec 2013 07:19:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2611AE0AA for ; Thu, 5 Dec 2013 07:19:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB5FJIUK030128; Thu, 5 Dec 2013 16:19:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 31C022027EE; Thu, 5 Dec 2013 16:19:27 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1AF1A2025EB; Thu, 5 Dec 2013 16:19:27 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB5FJHCB018923; Thu, 5 Dec 2013 16:19:17 +0100 Message-ID: <52A09975.1010605@gmail.com> Date: Thu, 05 Dec 2013 16:19:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ole Troan References: <52A07C4E.5050004@gmail.com> <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> In-Reply-To: <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:19:30 -0000 Le 05/12/2013 16:06, Ole Troan a écrit : > Alexandru, > >> For example, Prefix Delegation is only specified for DHCPv6 (not >> for RA), whereas the MTU parameter, and default router parameters >> (IP address, MAC address) are only for the RA (not for DHCP). > > that's because prefix delegation is a stateful operation that > requires per requesting router / client binding state. the general > principle is "DHCPv6 can give different information to different > clients, RA give the same information to everyone." YEs, I agree. Alex (and, as with all preceding points it is also a yes/no matter. The address assignment (not only Prefix Delegation) DHCP is also a stateful matter needing binding state about the requester. Yes, the RA also (not only DHCP) can give different information to different clients, as may be used in Proxy Mobile IPv6 (the MAG gives a different prefix to each Host and the MAG emitting the RA keeps state about that assignment).) > > cheers, Ole > From Fred.L.Templin@boeing.com Thu Dec 5 08:05:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61DF1AE0A7 for ; Thu, 5 Dec 2013 08:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkRoIioItPsv for ; Thu, 5 Dec 2013 08:04:59 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id C118C1AE07C for ; Thu, 5 Dec 2013 08:04:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id rB5G4uO0007753; Thu, 5 Dec 2013 08:04:56 -0800 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rB5G4m2b007680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 5 Dec 2013 08:04:48 -0800 Received: from XCH-BLV-401.nw.nos.boeing.com (130.247.25.18) by XCH-PHX-310.sw.nos.boeing.com (130.247.25.169) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Dec 2013 08:04:48 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.231]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 08:04:46 -0800 From: "Templin, Fred L" To: Alexandru Petrescu , Ole Troan Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO8c1tkgadrDtgk0KdxZxxm9/KJ5pFw2BQ Date: Thu, 5 Dec 2013 16:04:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831816F313@XCH-BLV-504.nw.nos.boeing.com> References: <52A07C4E.5050004@gmail.com> <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> <52A09975.1010605@gmail.com> In-Reply-To: <52A09975.1010605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:05:01 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Thursday, December 05, 2013 7:19 AM > To: Ole Troan > Cc: V6 Ops List > Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dh= cpv6-comparison-00.txt (fwd) >=20 > Le 05/12/2013 16:06, Ole Troan a =E9crit : > > Alexandru, > > > >> For example, Prefix Delegation is only specified for DHCPv6 (not > >> for RA), whereas the MTU parameter, and default router parameters > >> (IP address, MAC address) are only for the RA (not for DHCP). > > > > that's because prefix delegation is a stateful operation that > > requires per requesting router / client binding state. the general > > principle is "DHCPv6 can give different information to different > > clients, RA give the same information to everyone." >=20 > YEs, I agree. This is true for multicast RAs, but unicast RAs can give different information to different clients. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > (and, as with all preceding points it is also a yes/no matter. >=20 > The address assignment (not only Prefix Delegation) DHCP is also a > stateful matter needing binding state about the requester. >=20 > Yes, the RA also (not only DHCP) can give different information to > different clients, as may be used in Proxy Mobile IPv6 (the MAG gives a > different prefix to each Host and the MAG emitting the RA keeps state > about that assignment).) > > > > cheers, Ole > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ayourtch@cisco.com Thu Dec 5 08:24:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E5D1AE0AA for ; Thu, 5 Dec 2013 08:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlXAnJE6bPG0 for ; Thu, 5 Dec 2013 08:24:16 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 055541AE0A3 for ; Thu, 5 Dec 2013 08:24:15 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB5GOBhI005907 for ; Thu, 5 Dec 2013 17:24:12 +0100 (CET) Received: from dhcp-10-149-4-110.cisco.com (dhcp-10-149-4-110.cisco.com [10.149.4.110]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB5GOAwN023029; Thu, 5 Dec 2013 17:24:10 +0100 (CET) Date: Thu, 5 Dec 2013 17:24:10 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Alexandru Petrescu In-Reply-To: <52A09821.20008@gmail.com> Message-ID: References: <52A07C4E.5050004@gmail.com> <52A09821.20008@gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1832655546-1386260650=:68814" Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:24:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1832655546-1386260650=:68814 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 5 Dec 2013, Alexandru Petrescu wrote: > Le 05/12/2013 15:40, Andrew Yourtchenko a écrit : >> Thanks a lot for the comments! >> >> inline... >> >> On Thu, 5 Dec 2013, Alexandru Petrescu wrote: >> >>> Thanks for the draft. IMHO it goes in a good direction to compare what >>> can be done with DHCPv6 vs RA. >>> >>> I have some comments. >>> >>>> DHCPv6 needs at least 2 packets. RA is just one packet. >>> >>> This varies. It is mainly yes. >>> >>> But, an initial exchange is at minimum 4 DHCPv6 messages (including a >>> costly discovery), >> >> What about Rapid Commit ? I was under impression there you can do the >> address assignment with just two messages. > > I guess so yes. I doubt though it is the most used mode. Of course, one > would just say Rapid Commit in this draft and it would be sufficient at this > level. Yeah - thanks, since it was a tiny change I made the edit to XML directly: https://github.com/ayourtch/ra-dhcpv6/commit/e5c01b6135f0c08c988189718fad24778843e4a6#diff-d6f2c9835b8f2c82e0ca00aad009d0cb > >> By "Costly" I assume you mean the "takes a long time because of the long >> inbuilt timeouts", as in the paragraph further below, I comment there. > > Yes. > > The longer the timeouts the higher the chances to discover something. The > shorter the timeouts the higher the chances to miss some important server. > If anyone who reads this sentence has seen more than 3 answers on a DHCP client with standard deviation of RTT of more than 1 second, please tell me more about the circumstances you saw it in. (The reason for asking it in this way I think in the DHCP case it would be more a pathology than a feature, contrary to e.g. mDNS case discovery where while you are waiting maybe a new service has arrived on the network - but, I would like to understand better what I missed in my assessment). (NB: not including the "pathologically reliable" link-layer scenario, which tries to achieve 0% packet loss by retransmitting over a course of a minute, I put a separate issue for it). >>> whereas a DAD-less operation would be a single RA >>> message (forgetting the initial MLD 'join'). >> >> No, it would be an RS-RA sequence - *unless* either RA interval is every >> few seconds or the host is lucky enough to be connected just before the >> periodic RA is sent. > > Yes, but there is an additional thing. > > The multicast RA works only if the Host has first subscribed to that group. > And that needs an additional initial message from the Host to everybody else > (the MLD 'join'). > > Basically, if the Host does not send that MLD message it will not receive the > periodic multicast RA either. Given the destination of periodic RAs is the all-nodes multicast, this statement would be in conflict with: http://tools.ietf.org/html/rfc3810: The link-scope all-nodes multicast address, (FF02::1), is handled as a special case. On all nodes -- that is all hosts and routers, including multicast routers -- listening to packets destined to the all-nodes multicast address, from all sources, is permanently enabled on all interfaces on which multicast listening is supported. No MLD messages are ever sent regarding neither the link-scope all-nodes multicast address, nor any multicast address of scope 0 (reserved) or 1 (node-local). http://www.ietf.org/rfc/rfc4541.txt: In IPv6, the data forwarding rules are more straight forward because MLD is mandated for addresses with scope 2 (link-scope) or greater. The only exception is the address FF02::1 which is the all hosts link-scope address for which MLD messages are never sent. Packets with the all hosts link-scope address should be forwarded on all ports. So, I think an all-routers destined RS + all-host destined RA is the "timely minimum", whereas the single periodic RA is the "absolute minimum", and the DHCPv6 case the 2 packet exchange is both. > >> (I >> >>> >>>> There is one additional reason for the DHCPv6 to be slower. >>> >>> One of the reasons DHCPv4/v6 may be slower lies in the discovery phase. >>> Every discovery phase takes some time. Old DHCPv4 implementations take >>> too much time, as do old WiFi 'scanning' operations (another discovery). >>> >> >> I found this snippet in RFC3315 interesting: >> >> "A client MUST collect Advertise messages for the first RT seconds, >> unless it receives an Advertise message with a preference value of >> 255. The preference value is carried in the Preference option >> (section 22.8). Any Advertise that does not include a Preference >> option is considered to have a preference value of 0. If the client >> receives an Advertise message that includes a Preference option with >> a preference value of 255, the client immediately begins a client- >> initiated message exchange (as described in section 18) by sending a >> Request message to the server from which the Advertise message was >> received. If the client receives an Advertise message that does not >> include a Preference option with a preference value of 255, the >> client continues to wait until the first RT elapses. If the first RT >> elapses and the client has received an Advertise message, the client >> SHOULD continue with a client-initiated message exchange by sending a >> Request message. >> " >> >> This means that in the case of a single-server, the discovery phase can >> be shortened by having the Preference of 255 - thus to be able to reduce >> the discovery process ? (I need to test if the hosts actually do this >> IRL, I suspect they do not). > > I guess yes, the paragraph above reflects a good way for DHCP behaviour to > approach that ideal of a single exchange. > ok. I think I already added that text, but I wanted to test if this "really" works and is practically configurable on at least one implementation - then it could become a reasonable BCP for a network that wants to have the best user experience. >>> Better implementations of the discovery phases take shorter time, yet >>> they are extremely lengthy compared to what agreed numbers and multicast >>> join/leave operations can achieve. >> >> ... "in the case of 0% packet loss". >> >> Add any packet loss and a single-packet scheme of RA becomes fragile and >> the worst case is dramatically worse than that of the DHCP. > > I agree. > >>>> An RA-based protocol interaction may influence host's routing. A >>>> DHCPv6-based interaction today can not influence the host's routing >>>> - it was specifically denied any and all involvement into routing. >>> [...] >>>> FIXME: This section needs further debates, clarifications, and a >>>> rewrite. Discussion welcome. >>> >>> There is an ongoing discussion in the DHC WG about this. Namely about >>> routing at DHCP Relay during Prefix Delegation. Implementations >>> consider seriously 'snooping' and adding routing table entries at Relay >>> during DHCP operations. Standards e.g. BBF require a solution to this >>> problem. >>> >>> There were several drafts and presentations during recent 2-3 years. >>> Most recent draft is at >>> draft-petrescu-relay-route-pd-problem-00.txt >> >> Yes, the Prefix Delegation is a completely special beast! I reread the >> RFC3633 - it does not even talk about DHCP servers - it talks about >> routers quite explicitly! > > I think the PD RFC defines a Delegating Router to be a DHCP Server, and then > only talks DR. Ah, ok I missed that. So, indeed there *are* cases that "router==dhcp server". > >> I will try to reflect this somehow, created the >> https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks! >> [snip] >>> RA), whereas the MTU parameter, and default router parameters (IP >>> address, MAC address) are only for the RA (not for DHCP). >> >> Do you have somewhere this work ? I would be happy to incorporate it. >> Else, maybe it's worth to start rebuilding it in the appendix. > > There is this paragraph only in draft-mouton-mif-dhcpv6-drlo-02 Thanks! >> In addition to the default router address, lifetime and link-layer >> address, the neighbor discovery mechanism also provides MTU, hop >> limit, reachable time, retransmission timer[...] > > But I would very well see a table like this: > > | Configured by | > +-------------+-------------+ > Parameter on Host | DHCP | RA | > -------------------+-------------+-------------+ > Default Router IP | | X | > -------------------+-------------+-------------+ > Default Router MAC | | X | > -------------------+-------------+-------------+ > Global Address | X | X (w/ other)| > -------------------+-------------+-------------+ > Delegated Prefix | X | | > -------------------+-------------+-------------+ > Link MTU | | X | > -------------------+-------------+-------------+ > Hop Limit | | X | > -------------------+-------------+-------------+ > Link's reachable | | X | > time, retr timer | | | > -------------------+-------------+-------------+ > DNS Resolver | X | X | > -------------------+-------------+-------------+ > Makes sense. I've added this into the "issue" and will XMLify / add reference later. Thanks a lot! --a > Alex > >> >> I'll be tracking it in https://github.com/ayourtch/ra-dhcpv6/issues/6. >> >> --a >> >>> >>> Alex >>> >>> Le 27/11/2013 14:06, Andrew Yourtchenko a écrit : >>>> Hello all, >>>> >>>> Finally I managed to comb a little bit and finally submit the doc >>>> that aims to compare RAs with DHCPv6 which emerged from the >>>> discussion on this list a few weeks ago. >>>> >>>> I'll be very happy to hear any comments, suggestions, flames, etc. >>>> >>>> --a >>>> >>>> >>>> p.s. The "realtime changes" repository is at: >>>> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the >>>> feedback via a pull request :) >>>> >>>> ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013 >>>> 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko >>>> Subject: New Version Notification for >>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>>> >>>> >>>> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>>> has been successfully submitted by Andrew Yourtchenko and posted to >>>> the IETF repository. >>>> >>>> Filename: draft-yourtchenko-ra-dhcpv6-comparison Revision: >>>> 00 Title: A comparison between the DHCPv6 and RA based host >>>> configuration Creation date: 2013-11-27 Group: Individual >>>> Submission Number of pages: 12 URL: >>>> http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>>> >>>> >>>> >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison >>>> >>>> >>> Htmlized: >>>> http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 >>>> >>>> >>>> Abstract: This document attempts to make a balanced comparison >>>> between the RA- based and DHCPv6-based host configuration mechanisms. >>>> It compares the two on different aspects, e.g: underlying media >>>> assumptions, coordination, locality, etc. and highlights the strong >>>> and weak sides of both protocols for each scenario. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at >>>> tools.ietf.org. >>>> >>>> The IETF Secretariat _______________________________________________ >>>> v6ops mailing list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> >>> > > --0-1832655546-1386260650=:68814-- From sarikaya2012@gmail.com Thu Dec 5 09:53:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0A1AE107 for ; Thu, 5 Dec 2013 09:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRSuDWgXSGXm for ; Thu, 5 Dec 2013 09:53:18 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2156A1A1F66 for ; Thu, 5 Dec 2013 09:53:17 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so10170583lbi.15 for ; Thu, 05 Dec 2013 09:53:14 -0800 (PST) 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=B419kT6ID2Mis4FOFygdazNEiPR9RlI43+9ArQdlGn4=; b=RH01RIS0G8Hw+6LoyGR/B86UarsacLxpf0tPjNvZmodgqZzT/YlETAapYHlbfR65oI 22/mxq4n5BGbOfcu0XDQEdG1lzKcHevNg3SVHOe0MLh0xFn0EXKLbN3xptFogANsObs4 Ax6OThgrEkXvsHBuqiclczeHEDi/eLpCxV66trmW26EchTxKwO4nNXHH8N/tEMMnbsIn 9i4LbjdqlvmIgzHa/Q+6eDFlmXOBx8CkqGvAwZOU0zbZmGPnl4N+Hz/idj5NOibjHSso 1Dsbx9VbAtvod9swt6zgESMQ4Pb2FQXIhPl+VrXiRrlYrw4RR2oWMXGmoiErlQDNV6DN xg3g== MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr7882144lam.22.1386265993985; Thu, 05 Dec 2013 09:53:13 -0800 (PST) Received: by 10.114.217.129 with HTTP; Thu, 5 Dec 2013 09:53:13 -0800 (PST) In-Reply-To: <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> References: <52A07C4E.5050004@gmail.com> <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> Date: Thu, 5 Dec 2013 11:53:13 -0600 Message-ID: From: Behcet Sarikaya To: Ole Troan Content-Type: multipart/alternative; boundary=089e0160b7be231ad204eccd34f5 Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 17:53:19 -0000 --089e0160b7be231ad204eccd34f5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 5, 2013 at 9:06 AM, Ole Troan wrote: > Alexandru, > > > For example, Prefix Delegation is only specified for DHCPv6 (not for > > RA), whereas the MTU parameter, and default router parameters (IP > > address, MAC address) are only for the RA (not for DHCP). > > that's because prefix delegation is a stateful operation that requires per > requesting router / client binding state. > the general principle is "DHCPv6 can give different information to > different clients, RA give the same information to everyone." > > Unless RA is sent on a point-to-point link. Behcet > cheers, > Ole > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --089e0160b7be231ad204eccd34f5 Content-Type: text/html; charset=ISO-8859-1



On Thu, Dec 5, 2013 at 9:06 AM, Ole Troan <otroan@employees.org> wrote:
Alexandru,

> For example, Prefix Delegation is only specified for DHCPv6 (not for
> RA), whereas the MTU parameter, and default router parameters (IP
> address, MAC address) are only for the RA (not for DHCP).

that's because prefix delegation is a stateful operation that requires per requesting router / client binding state.
the general principle is "DHCPv6 can give different information to different clients, RA give the same information to everyone."


Unless RA is sent on a point-to-point link.

Behcet
cheers,
Ole


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--089e0160b7be231ad204eccd34f5-- From markzzzsmith@yahoo.com.au Thu Dec 5 11:50:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85D71AE142 for ; Thu, 5 Dec 2013 11:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJX7dfdmV3rI for ; Thu, 5 Dec 2013 11:50:04 -0800 (PST) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with SMTP id 470EC1AE16A for ; Thu, 5 Dec 2013 11:50:04 -0800 (PST) Received: from [66.196.81.173] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 05 Dec 2013 19:50:00 -0000 Received: from [98.139.212.213] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 05 Dec 2013 19:50:00 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 05 Dec 2013 19:50:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 682853.26136.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 10640 invoked by uid 60001); 5 Dec 2013 19:50:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1386273000; bh=Fv0mZUYAgvblhZ0uNT+R82sbEw4JVJEZhNpQUkEvNVQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rgvJAqT8YkxN9OQOkRCFMoA1UgtOAS+fAQa5iDp4JmJ5TC4q2LMOiqQVAFRz414ecwXhpRGKIdcQFWK2hqnuXdDKdI+PYWKFjqKD7FNuzb3M400s+GcBIyQCQn1AZ/3FBPa0St/bg9aijATvPBY7gDMc8EMQFhdCgopeK40uyxg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dzIrIQWpkQHP6V0lm/gqlkN63KiTW8jdVNRJpu2WiPIiezoy6T1PwE9Gq0HuV4fGfefkv8d3yvxri0fCR/ITvkX3qqIW4MA+oT34p3uJRSjWIEJ9a/IdTRR32KRCz2Ce+lJWlW3WKdm2jsfIOAlReqlqcWb2iiadZ/4YQJY1tS4=; X-YMail-OSG: Bmiizo0VM1noM8V7LKHOB5IDA0ZOPBo2EvaHHhVP23bNpNN yPYVeCTBduJkcTY7ecS67FSxKH10PpHHOkwjcdOhRI4Hh3mwqUvkHWvqGczb .1y9kYXeMeCy39mN0wmADI33dXvsi3MeGPdEuKr_vyNdvAQWl7RdI4SEvKp_ e4xIEaS84n5UFUdgydCG8CfjQmzZ0JKBtj5PBZTIsE8zgyopjpDJboxA94Rh T6hHZXFjYlf9d7uZPLDDxpV49HEbq3rtuy4mG4M5yfAhY0XcacBk11ZKAb8B uSQephDUEuNK_8td4rRX3bRWtUsKNzGSgThwmOd5LKGZsnFtwpCJRXDAyTvS 6AroLx82XQSWFxhsg1gPOZ56riQEQBJvxVf.Pt3EE_BBE4CTM9EwBjDgkhTE vR5FXmZ6csXSUAw2Aj5z4TdOcg65KwFgRV_GZTY1JrS92q756xDjZViAWyn7 03rmr8ATKBLEDBamiRrGkbjuZrtOX7C8BGNMTBOEkyIttDyMLrrE_j5IgD43 iIUf2nYkyiUdmk.f.24OU3M_l.h1GnivLZ6ivbO1.Hx8PnyZ.Ldl8cRkAuK4 dAuKe0rKpeV7nSRGt7cy2lekdUQ-- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Thu, 05 Dec 2013 11:50:00 PST X-Rocket-MIMEInfo: 002.001, LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQoKPiBGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj4gVG86IE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc.Cj4gQ2M6IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBGcmlkYXksIDYgRGVjZW1iZXIgMjAxMyAyOjE5IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15b3VydGNoZW5rby1yYS1kaGNwdjYtY29tcGFyaXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <52A07C4E.5050004@gmail.com> <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> <52A09975.1010605@gmail.com> Message-ID: <1386273000.69006.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Thu, 5 Dec 2013 11:50:00 -0800 (PST) From: Mark ZZZ Smith To: Alexandru Petrescu , Ole Troan In-Reply-To: <52A09975.1010605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:50:05 -0000 ----- Original Message -----=0A=0A> From: Alexandru Petrescu =0A> To: Ole Troan =0A> Cc: V6 Ops Li= st =0A> Sent: Friday, 6 December 2013 2:19 AM=0A> Subject: = Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-compar= ison-00.txt (fwd)=0A> =0A> Le 05/12/2013 16:06, Ole Troan a =E9crit :=0A>> = Alexandru,=0A>> =0A>>> For example, Prefix Delegation is only specified f= or DHCPv6 (not=0A>>> for RA), whereas the MTU parameter, and default route= r parameters=0A>>> (IP address, MAC address) are only for the RA (not for = DHCP).=0A>> =0A>> that's because prefix delegation is a stateful operation= that=0A>> requires per requesting router / client binding state. the gene= ral=0A>> principle is "DHCPv6 can give different information to different= =0A>> clients, RA give the same information to everyone."=0A> =0A> YEs, I = agree.=0A>=A0=0A=0ARAs can be used to distribute client specific parameters= , for the parameters that RAs carry, as has been implemented in the widely = deployed radvd open source RA daemon (see the 'clients' option).=0A=0AA mec= hanism to distribute these client specific RA parameters to routers isn't c= ommonly available, however RADIUS could be used for that purpose, similar t= o how RADIUS is being used to distribute parameters to a router located DHC= Pv6 server.=A0=0A=0A=0A> Alex=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> = =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> (and, as with a= ll preceding points it is also a yes/no matter.=0A> =0A> The address assign= ment (not only Prefix Delegation) DHCP is also a=0A> stateful matter needin= g binding state about the requester.=0A> =0A> Yes, the RA also (not only DH= CP) can give different information to=0A> different clients, as may be used= in Proxy Mobile IPv6 (the MAG gives a =0A> different prefix to each Host a= nd the MAG emitting the RA keeps state =0A> about that assignment).)=0A> = =0A>> =0A>> cheers, Ole=0A>> =0A> =0A> =0A> ______________________________= _________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www= .ietf.org/mailman/listinfo/v6ops=0A> From otroan@employees.org Thu Dec 5 11:52:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE3B1A802A for ; Thu, 5 Dec 2013 11:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0NYlupEyClL for ; Thu, 5 Dec 2013 11:52:40 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA11A16F0 for ; Thu, 5 Dec 2013 11:52:39 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHvYoFKQ/khR/2dsb2JhbABZgwe5eIEcFnSCJQEBAQMBdwIFCwtGVwaIDwayKI8xF48AB4MggRMDkDGZdoFrgT87 X-IronPort-AV: E=Sophos;i="4.93,835,1378857600"; d="asc'?scan'208";a="1746273" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 05 Dec 2013 19:52:35 +0000 Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB5JqV2G014937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 19:52:31 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_3282A6EB-4BED-4D9B-ADCA-E8AEA0018E1F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <1386273000.69006.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Thu, 5 Dec 2013 20:52:30 +0100 Message-Id: <66095780-022E-4DD4-98EB-B9C56E0B8EA9@employees.org> References: <52A07C4E.5050004@gmail.com> <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> <52A09975.1010605@gmail.com> <1386273000.69006.YahooMailNeo@web142503.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1822) Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:52:41 -0000 --Apple-Mail=_3282A6EB-4BED-4D9B-ADCA-E8AEA0018E1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 [...] > RAs can be used to distribute client specific parameters, for the = parameters that RAs carry, as has been implemented in the widely = deployed radvd open source RA daemon (see the 'clients' option). >=20 > A mechanism to distribute these client specific RA parameters to = routers isn't commonly available, however RADIUS could be used for that = purpose, similar to how RADIUS is being used to distribute parameters to = a router located DHCPv6 server.=20 yes, I was talking about the general operation of the protocol. cheers, Ole --Apple-Mail=_3282A6EB-4BED-4D9B-ADCA-E8AEA0018E1F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSoNl+AAoJEFuJXizso86gYI4H/2UBNA51r6Atgjyl3i9znPZ8 5MOyBt7VfmEZ4hbL6X2QxrrZUIS5WT2E1FxwoFcga/7agxj5iPUdYIVSXcx3GgQU PlZuqzZO8v8yUv9Bb/2RH6Uf75HzIH8JYwZWDIDiE9RIT38svj7wCr0IYqlonQR8 a6+w179dfttbJ0UQJAGmc2K5w7HWoS0jWO8Ts6yIj8CFfUJy1GKdy6eB7/gHLtjx 1hXjFybHBLUIJGveXsZ0WUmJB9rNOk5UjEFnwRwyJewe9GkNeQaEHQBtmu+543fN SwZFblQXe/R9MQF1sR2u3cRlnPc2gbwCjNTfRRGfCwkE5G/oZEOgIgh3r0EsbIs= =JSS6 -----END PGP SIGNATURE----- --Apple-Mail=_3282A6EB-4BED-4D9B-ADCA-E8AEA0018E1F-- From markzzzsmith@yahoo.com.au Thu Dec 5 12:20:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A71AE174 for ; Thu, 5 Dec 2013 12:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2qZKjoexIEg for ; Thu, 5 Dec 2013 12:20:08 -0800 (PST) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with SMTP id 19A6E1AE181 for ; Thu, 5 Dec 2013 12:19:50 -0800 (PST) Received: from [98.139.215.141] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 05 Dec 2013 20:19:46 -0000 Received: from [98.139.212.211] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 05 Dec 2013 20:19:46 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 05 Dec 2013 20:19:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 556216.28579.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 27889 invoked by uid 60001); 5 Dec 2013 20:19:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1386274786; bh=lR3KvoITWFrFFyN1+AKa4NQwoXQH0y5Wz9FnMsyLeGg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QcS0+Te6Lv7AwFIEbFFGaQ5TcsYkxJvUoqbt0lh9GSgOGKQmHKLS/wmr0c1EPcyV3KFTLQ4iK4990B/YPNKsWlkHL6KyooRF/xaC3PHUN6KS4+xX4Iuk3Ijb3oZmNQO40xx3miCid1/zGj1HH1ECcseUA6fJbOMmUL2sR4Cjg90= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Tof4TZczYhBcrc1tYVZ42ymHpP12vCrrJQVEPSPOcMKb7GBKuIYzeRFGfyXPltTY15YNuQN0Bem5JOLEtmYaIbop14v/twZlYF1azCnomdFrEJX1+pBPQz26H6UqBu706r1oiVaYoCycALF7KIJ6mC/0fLC+XH3cpsgzAyExsWo=; X-YMail-OSG: Zxrs7kQVM1mdoH0m9wNfxJsl8U3tBw5PpKA.8Dm1JFGZt31 hb3qrz0hQJzWrn1m3SsD7abj0bJcB3nAn4aAmFSym4b.LeHrwvgf7rxaf.sX YzogKWGCiudx3UxS..SWJKBg8iZyfLPYGJakZ2ZvOT1gnWC.1yW03n1qfHsn kKWE7fngFjwP7c4_WA.broADR4yCfwIytLEOfLK2W9a1N91ZAHoY2b6raivZ wiW9yQDR5NC8UL.kg4ZDNowz5_UAWRs4lVasHBuSUElVN4AvWSJ6Q.fpzhHy VtKw1HRJvqThLYHdvha_gpvJg.XZ.ElrXR5rv5eH7o8sv7L0Zs1bFJMG746T UKB539fs2QsXZdWXRKIWYI_UmNlaEO.DjcsOxWMMupQe5W4IpxbM3TaaSJGc VvAPXwC8uEY0Zunda5x6Tknn3ehzuf4kLVsbbwQTQmreUPiqp1izCfjbtXb4 fasH1bAaPouyl_fRX67RRt03EJewrAptYARCRXz5zOGZrkMrR3otoEyBMpYA E88rjO1iYrRVFHKp34zjfT8yYQ6bUdW5KWktJV9uhdM5THRsQvSgHsx7j5bi 2TKuzY0AaqSDV2nlfkxeQ Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Thu, 05 Dec 2013 12:19:46 PST X-Rocket-MIMEInfo: 002.001, SGksCgpTb21lIGNyaXRpY2lzbXMvY29tbWVudHMvcXVlc3Rpb25zIG9uIHRoZXNlIHBpZWNlcyBvZiB0ZXh0IHJlbGF0aW5nIHRvIGxheWVyIDIvd2lmaSBtdWx0aWNhc3QgcmVsaWFibGl0eToKCiJUaGlzIGlzIHdoZXJlIHRoZSBwZWVyLXRvLXBlZXIsIGFja25vd2xlZGdlZCBuYXR1cmUgb2YgREhDUHY2IG1heSBiZQpiZW5lZmljaWFsIC0gb24gYSBjcm93ZGVkIGxhcmdlLXNjYWxlIFdpRmksIHdpdGhvdXQgc3BlY2lhbCB0cmlja3MgdG8gZW5zdXJlIHRoZSByZWxpYWJsZSBkZWxpdmVyeSBvZiBtdWx0aWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: Message-ID: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 5 Dec 2013 12:19:46 -0800 (PST) From: Mark ZZZ Smith To: Andrew Yourtchenko , "v6ops@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:20:09 -0000 Hi,=0A=0ASome criticisms/comments/questions on these pieces of text relatin= g to layer 2/wifi multicast reliablity:=0A=0A"This is where the peer-to-pee= r, acknowledged nature of DHCPv6 may be=0Abeneficial - on a crowded large-s= cale WiFi, without special tricks to ensure the reliable delivery of multic= ast packets, you simply will not get the SLAAC working because the multicas= t RAs will get crunched by the interference."=0AI'd think that if multicast= is unreliable enough to cause RAs to fail to be delivered often enough, th= en anything which relies on multicast traffic is also likely to fail, which= would include neighbor discovery. So regardless of if RAs were replaced wi= th DHCPv6, the link is not going to provide reliable IPv6 operation, becaus= e IPv6=A0addresses cannot be reliably resolved to layer 2 addresses.=A0=0AM= LD would probably fail too, so any routed multicast applications, even low = bandwidth ones, wouldn't work either, as would MLD snooping based layer 2 f= orwarding optimisation.=0ADHCPv6 uses multicast for DHCPv6 server/relay dis= covery, so that will probably be unreliable as well.=0A=0AI don't think bro= adcasts on wifi are reliable, so IPv4 ARP would be failing too.=0A=0ASo if = RAs are failing because of not reliable enough multicast then that is just = one symptom of the link being overloaded, and there will be others.=0AOne i= dea I've had for this sort of scenario would be for the link to operate as = mostly an IPv6 over NBMA segment. The only multicasts on the link are RAs, = providing the necessary NBMA operation parameters. It of course would requi= re changes to clients and routers, but then again, so would using DHCPv6 fo= r what RAs are used for today.=0A=0A"Alternatively, in a very mobile enviro= nment and the RFC-compliant=0A=0Arouter, multicast solicited RAs might make= a significant portion of your traffic - which, due to a difference in modu= lation, etc. may eat way more bandwidth than if they were sent unicast."= =0A=0AThe MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a lin= k can't handle 1 multicast every few seconds, it's also past the point of i= t's capacity (and as above, other multicast/broadcast would also be contrib= uting to exceeding link capacity.)=0A=0ARegards,=0AMark.=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A----- Original Message -----=0A> From: Andrew Yourtchenko =0A> To: v6ops@ietf.org=0A> Cc: =0A> Sent: Thursday, 28 N= ovember 2013 12:06 AM=0A> Subject: [v6ops] New Version Notification for dra= ft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)=0A> =0A> Hello all,=0A> = =0A> Finally I managed to comb a little bit and finally submit the doc that= =0A> aims to compare RAs with DHCPv6 which emerged from the discussion on = this =0A> list a few weeks ago.=0A> =0A> I'll be very happy to hear any com= ments, suggestions, flames, etc.=0A> =0A> --a=0A> =0A> =0A=0A> From internet-drafts@ietf.org Fri Dec 6 07:38:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0881ADF71; Fri, 6 Dec 2013 07:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44z_g-fFi-Pw; Fri, 6 Dec 2013 07:38:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 761591AE011; Fri, 6 Dec 2013 07:38:34 -0800 (PST) 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 X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 07:38:34 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:38:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Balanced Security for IPv6 Residential CPE Author(s) : Martin Gysi Guillaume Leclanche Eric Vyncke Ragnar Anfinsen Filename : draft-ietf-v6ops-balanced-ipv6-security-01.txt Pages : 9 Date : 2013-12-06 Abstract: This document describes how an IPv6 residential Customer Premise Equipment (CPE) can have a balanced security policy that allows for a mostly end-to-end connectivity while keeping the major threats outside of the home. It is documenting an existing IPv6 deployment by Swisscom and allows all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known. The policy is a proposed set of rules that can be used as a default setting. The set of blocked inbound and outbound ports is expected to be updated as threats come and go. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-balanced-ipv6-security-= 01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From guillaume@leclanche.net Fri Dec 6 07:52:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB01ADFAF for ; Fri, 6 Dec 2013 07:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MISSING_HEADERS=1.021] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIwEUywVrIOZ for ; Fri, 6 Dec 2013 07:52:42 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D502D1ADFFB for ; Fri, 6 Dec 2013 07:52:41 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id ht10so908507vcb.29 for ; Fri, 06 Dec 2013 07:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leclanche.net; s=leclanche-net; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=7yChUcr+hkv+0yMjgHeFu0lqIKtbxxJ4iqkBWDvhp4Y=; b=nVHGekfi3SMD1lnxV3R3OcsRumRcJ3qTX2J3dLPciqOwpv5heBeAcu0Zdki4rS0GJV LPiN/89p1TbwPjEByUTA14+Cnap5/uAzxYh4ehZ45Qg1bKU48uDlsk4i7wHRDotpEqui EDFzO7wKPLcKweIIJOrhxv3FjjamKe27Yzrt4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc:content-type; bh=7yChUcr+hkv+0yMjgHeFu0lqIKtbxxJ4iqkBWDvhp4Y=; b=WbnEwcNZK5vEwGZLRFJVOY2wYHvfWJIAynYxZ6k9IVhTYFMPv2lpaeek/MvI4G9SUh DoxIpIRvyeBbas5s99g8gwZvf1tO65vTlf1pWZyGXTh6Up1IzXc4jmXgMXRM+fuVR6y4 QMsDsxJdgPZyIA9hseu9TJgaro9z9RgHZINKPJ5XDAT5OkEPbRdgzQrcFRa5T1kthOvz NDRJs33ASVeIleT+EdZ1mwavN36eAF+Y4D7MFiApW2AbETrGyTs7k27u4TRhwe4V0hOf jnFF5Wyvxz5I1Y6CigC7tMrKRhP237sCLuDT3PAAqvS4UCuu8YhUfBn7e5vOnv9EDNjf 9tjQ== X-Gm-Message-State: ALoCoQmqUeRTSn87X0gaBlbWkkiL2ZMdVeZSUuo2lQyKzG31Xov10If0edYgOfy+RkTQP+MGE8M7 X-Received: by 10.220.50.18 with SMTP id x18mr2392367vcf.29.1386345157741; Fri, 06 Dec 2013 07:52:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.24.200 with HTTP; Fri, 6 Dec 2013 07:51:57 -0800 (PST) X-Originating-IP: [2620:0:230:c000:3e97:eff:fe95:5451] In-Reply-To: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> From: Guillaume Leclanche Date: Fri, 6 Dec 2013 10:51:57 -0500 Message-ID: Cc: "v6ops@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:52:43 -0000 Hello, This is a new version of the draft after having analyzed the WGLC comments and the Security Directorate review. A lot of text was modified to make sure that the document could not be mistaken for a recommendation. The filtering concept and examples are not changed, as the authors have chosen to stick to describing the documented practice. There are new mentions of PCP and UPnP, and the Security Considerations part was also detailed. Guillaume 2013/12/6 : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Balanced Security for IPv6 Residential CPE > Author(s) : Martin Gysi > Guillaume Leclanche > Eric Vyncke > Ragnar Anfinsen > Filename : draft-ietf-v6ops-balanced-ipv6-security-01.txt > Pages : 9 > Date : 2013-12-06 > > Abstract: > This document describes how an IPv6 residential Customer Premise > Equipment (CPE) can have a balanced security policy that allows for a > mostly end-to-end connectivity while keeping the major threats > outside of the home. It is documenting an existing IPv6 deployment > by Swisscom and allows all packets inbound/outbound EXCEPT for some > layer-4 ports where attacks and vulnerabilities (such as weak > passwords) are well-known. The policy is a proposed set of rules > that can be used as a default setting. The set of blocked inbound > and outbound ports is expected to be updated as threats come and go. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-balanced-ipv6-security-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Fri Dec 6 07:58:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290F01AE052 for ; Fri, 6 Dec 2013 07:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95U7zONNhirn for ; Fri, 6 Dec 2013 07:58:08 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A13DF1AE001 for ; Fri, 6 Dec 2013 07:58:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB6Fw1lH024416; Fri, 6 Dec 2013 16:58:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CDF15203629; Fri, 6 Dec 2013 16:58:11 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C22472035FE; Fri, 6 Dec 2013 16:58:11 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB6FvsTZ024588; Fri, 6 Dec 2013 16:58:01 +0100 Message-ID: <52A1F403.80702@gmail.com> Date: Fri, 06 Dec 2013 16:57:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andrew Yourtchenko References: <52A07C4E.5050004@gmail.com> <52A09821.20008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:58:11 -0000 Le 05/12/2013 17:24, Andrew Yourtchenko a écrit : [...] >> The multicast RA works only if the Host has first subscribed to that >> group. And that needs an additional initial message from the Host to >> everybody else (the MLD 'join'). >> >> Basically, if the Host does not send that MLD message it will not >> receive the periodic multicast RA either. > > Given the destination of periodic RAs is the all-nodes multicast, this > statement would be in conflict with: > > http://tools.ietf.org/html/rfc3810: > > The link-scope all-nodes multicast address, (FF02::1), is handled as > a special case. On all nodes -- that is all hosts and routers, > including multicast routers -- listening to packets destined to the > all-nodes multicast address, from all sources, is permanently enabled > on all interfaces on which multicast listening is supported. No MLD > messages are ever sent regarding neither the link-scope all-nodes > multicast address, nor any multicast address of scope 0 (reserved) or > 1 (node-local). Hmmm... I may need to try this, because I doubt it. Turn the machine on, while listening with another machine the packets emitted by the first. If there is an MLD message before any other RS then the RFC deserves a comment. > http://www.ietf.org/rfc/rfc4541.txt: > > In IPv6, the data forwarding rules are more straight forward because > MLD is mandated for addresses with scope 2 (link-scope) or greater. > The only exception is the address FF02::1 which is the all hosts > link-scope address for which MLD messages are never sent. Packets > with the all hosts link-scope address should be forwarded on all > ports. This RFC deserves a comment: that is the all nodes address (not all hosts). > So, I think an all-routers destined RS + all-host destined RA is the > "timely minimum", whereas the single periodic RA is the "absolute > minimum", and the DHCPv6 case the 2 packet exchange is both. Hmm, it seems so... but I'd first check the above. Anyways, your draft is right. Alex > >> >>> (I >>> >>>> >>>>> There is one additional reason for the DHCPv6 to be slower. >>>> >>>> One of the reasons DHCPv4/v6 may be slower lies in the discovery phase. >>>> Every discovery phase takes some time. Old DHCPv4 implementations take >>>> too much time, as do old WiFi 'scanning' operations (another >>>> discovery). >>>> >>> >>> I found this snippet in RFC3315 interesting: >>> >>> "A client MUST collect Advertise messages for the first RT seconds, >>> unless it receives an Advertise message with a preference value of >>> 255. The preference value is carried in the Preference option >>> (section 22.8). Any Advertise that does not include a Preference >>> option is considered to have a preference value of 0. If the client >>> receives an Advertise message that includes a Preference option with >>> a preference value of 255, the client immediately begins a client- >>> initiated message exchange (as described in section 18) by sending a >>> Request message to the server from which the Advertise message was >>> received. If the client receives an Advertise message that does not >>> include a Preference option with a preference value of 255, the >>> client continues to wait until the first RT elapses. If the >>> first RT >>> elapses and the client has received an Advertise message, the client >>> SHOULD continue with a client-initiated message exchange by >>> sending a >>> Request message. >>> " >>> >>> This means that in the case of a single-server, the discovery phase can >>> be shortened by having the Preference of 255 - thus to be able to reduce >>> the discovery process ? (I need to test if the hosts actually do this >>> IRL, I suspect they do not). >> >> I guess yes, the paragraph above reflects a good way for DHCP >> behaviour to approach that ideal of a single exchange. >> > > ok. I think I already added that text, but I wanted to test if this > "really" works and is practically configurable on at least one > implementation - then it could become a reasonable BCP for a network > that wants to have the best user experience. > >>>> Better implementations of the discovery phases take shorter time, yet >>>> they are extremely lengthy compared to what agreed numbers and >>>> multicast >>>> join/leave operations can achieve. >>> >>> ... "in the case of 0% packet loss". >>> >>> Add any packet loss and a single-packet scheme of RA becomes fragile and >>> the worst case is dramatically worse than that of the DHCP. >> >> I agree. >> >>>>> An RA-based protocol interaction may influence host's routing. A >>>>> DHCPv6-based interaction today can not influence the host's routing >>>>> - it was specifically denied any and all involvement into routing. >>>> [...] >>>>> FIXME: This section needs further debates, clarifications, and a >>>>> rewrite. Discussion welcome. >>>> >>>> There is an ongoing discussion in the DHC WG about this. Namely about >>>> routing at DHCP Relay during Prefix Delegation. Implementations >>>> consider seriously 'snooping' and adding routing table entries at Relay >>>> during DHCP operations. Standards e.g. BBF require a solution to this >>>> problem. >>>> >>>> There were several drafts and presentations during recent 2-3 years. >>>> Most recent draft is at >>>> draft-petrescu-relay-route-pd-problem-00.txt >>> >>> Yes, the Prefix Delegation is a completely special beast! I reread the >>> RFC3633 - it does not even talk about DHCP servers - it talks about >>> routers quite explicitly! >> >> I think the PD RFC defines a Delegating Router to be a DHCP Server, >> and then only talks DR. > > Ah, ok I missed that. So, indeed there *are* cases that "router==dhcp > server". > >> >>> I will try to reflect this somehow, created the >>> https://github.com/ayourtch/ra-dhcpv6/issues/5. Thanks! >>> > > [snip] > >>>> RA), whereas the MTU parameter, and default router parameters (IP >>>> address, MAC address) are only for the RA (not for DHCP). >>> >>> Do you have somewhere this work ? I would be happy to incorporate it. >>> Else, maybe it's worth to start rebuilding it in the appendix. >> >> There is this paragraph only in draft-mouton-mif-dhcpv6-drlo-02 > > Thanks! > >>> In addition to the default router address, lifetime and link-layer >>> address, the neighbor discovery mechanism also provides MTU, hop >>> limit, reachable time, retransmission timer[...] >> >> But I would very well see a table like this: >> >> | Configured by | >> +-------------+-------------+ >> Parameter on Host | DHCP | RA | >> -------------------+-------------+-------------+ >> Default Router IP | | X | >> -------------------+-------------+-------------+ >> Default Router MAC | | X | >> -------------------+-------------+-------------+ >> Global Address | X | X (w/ other)| >> -------------------+-------------+-------------+ >> Delegated Prefix | X | | >> -------------------+-------------+-------------+ >> Link MTU | | X | >> -------------------+-------------+-------------+ >> Hop Limit | | X | >> -------------------+-------------+-------------+ >> Link's reachable | | X | >> time, retr timer | | | >> -------------------+-------------+-------------+ >> DNS Resolver | X | X | >> -------------------+-------------+-------------+ >> > > Makes sense. I've added this into the "issue" and will XMLify / add > reference later. > > Thanks a lot! > > --a > > >> Alex >> >>> >>> I'll be tracking it in https://github.com/ayourtch/ra-dhcpv6/issues/6. >>> >>> --a >>> >>>> >>>> Alex >>>> >>>> Le 27/11/2013 14:06, Andrew Yourtchenko a écrit : >>>>> Hello all, >>>>> >>>>> Finally I managed to comb a little bit and finally submit the doc >>>>> that aims to compare RAs with DHCPv6 which emerged from the >>>>> discussion on this list a few weeks ago. >>>>> >>>>> I'll be very happy to hear any comments, suggestions, flames, etc. >>>>> >>>>> --a >>>>> >>>>> >>>>> p.s. The "realtime changes" repository is at: >>>>> https://github.com/ayourtch/ra-dhcpv6, in case you want to send the >>>>> feedback via a pull request :) >>>>> >>>>> ---------- Forwarded message ---------- Date: Wed, 27 Nov 2013 >>>>> 04:52:14 -0800 From: internet-drafts@ietf.org To: Andrew Yourtchenko >>>>> Subject: New Version Notification for >>>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>>>> >>>>> >>>>> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>>>> has been successfully submitted by Andrew Yourtchenko and posted to >>>>> the IETF repository. >>>>> >>>>> Filename: draft-yourtchenko-ra-dhcpv6-comparison Revision: >>>>> 00 Title: A comparison between the DHCPv6 and RA based host >>>>> configuration Creation date: 2013-11-27 Group: Individual >>>>> Submission Number of pages: 12 URL: >>>>> http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>>>> >>>>> >>>>> >>>>> >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-yourtchenko-ra-dhcpv6-comparison >>>>> >>>>> >>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 >>>>> >>>>> >>>>> Abstract: This document attempts to make a balanced comparison >>>>> between the RA- based and DHCPv6-based host configuration mechanisms. >>>>> It compares the two on different aspects, e.g: underlying media >>>>> assumptions, coordination, locality, etc. and highlights the strong >>>>> and weak sides of both protocols for each scenario. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> >>>>> The IETF Secretariat _______________________________________________ >>>>> v6ops mailing list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>> >>>> >> >> From alexandru.petrescu@gmail.com Fri Dec 6 07:59:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DA01AE044 for ; Fri, 6 Dec 2013 07:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v64_CjIg_pS7 for ; Fri, 6 Dec 2013 07:59:04 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 88EBB1AE001 for ; Fri, 6 Dec 2013 07:59:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB6FwtOo007611; Fri, 6 Dec 2013 16:58:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 70E5E203656; Fri, 6 Dec 2013 16:59:06 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 58234203655; Fri, 6 Dec 2013 16:59:06 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB6Fwtls025170; Fri, 6 Dec 2013 16:58:55 +0100 Message-ID: <52A1F43F.8010006@gmail.com> Date: Fri, 06 Dec 2013 16:58:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: sarikaya@ieee.org, Ole Troan References: <52A07C4E.5050004@gmail.com> <5CB06819-FF5E-4B51-8B81-9D6D2406BC8E@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:59:07 -0000 Le 05/12/2013 18:53, Behcet Sarikaya a écrit : > > > > On Thu, Dec 5, 2013 at 9:06 AM, Ole Troan > wrote: > > Alexandru, > > > For example, Prefix Delegation is only specified for DHCPv6 (not for > > RA), whereas the MTU parameter, and default router parameters (IP > > address, MAC address) are only for the RA (not for DHCP). > > that's because prefix delegation is a stateful operation that > requires per requesting router / client binding state. > the general principle is "DHCPv6 can give different information to > different clients, RA give the same information to everyone." > > > Unless RA is sent on a point-to-point link. Yes, and depends what we call a point-to-point link. Because there are point to point links which act so much as pure Ethernet (like CDC-Ethernet in 4G)... Alex > > Behcet > > cheers, > Ole > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From ayourtch@cisco.com Fri Dec 6 08:34:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970D11AE054 for ; Fri, 6 Dec 2013 08:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO8CELlUpqmA for ; Fri, 6 Dec 2013 08:34:42 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E71391ADFFB for ; Fri, 6 Dec 2013 08:34:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB6GYaIe001763 for ; Fri, 6 Dec 2013 17:34:36 +0100 (CET) Received: from dhcp-10-149-4-110.cisco.com (dhcp-10-149-4-110.cisco.com [10.149.4.110]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB6GYX6j019162; Fri, 6 Dec 2013 17:34:33 +0100 (CET) Date: Fri, 6 Dec 2013 17:34:33 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Mark ZZZ Smith In-Reply-To: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1852186906-1386327872=:68814" Content-ID: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:34:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1852186906-1386327872=:68814 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi Mark, On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: > Hi, > > Some criticisms/comments/questions on these pieces of text relating to layer 2/wifi multicast reliablity: > > "This is where the peer-to-peer, acknowledged nature of DHCPv6 may be > beneficial - on a crowded large-scale WiFi, without special tricks to >ensure the reliable delivery of multicast packets, you simply will not >get the SLAAC working because the multicast RAs will get crunched by the >interference." > I'd think that if multicast is unreliable enough to cause RAs to fail >to be delivered often enough, then anything which relies on multicast >traffic is also likely to fail, which would include neighbor discovery. >So regardless of if RAs were replaced with DHCPv6, the link is not going >to provide reliable IPv6 operation, because IPv6 addresses cannot be >reliably resolved to layer 2 addresses. > > MLD would probably fail too, so any routed multicast applications, even >low bandwidth ones, wouldn't work either, as would MLD snooping based >layer 2 forwarding optimisation. > > DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that will probably be unreliable as well. > > I don't think broadcasts on wifi are reliable, so IPv4 ARP would be failing too. > > So if RAs are failing because of not reliable enough multicast then >that is just one symptom of the link being overloaded, and there will be >others. I think I capture several points here, tell me if I get them correctly: 1) There are other protocols that use multicast that will fail. 2) Fix your link. for (1): RA is probably the only one that does not incorporate a robust retransmit mechanism. for (2): It's great if you can, but I'd like to have protocol work in all conditions. Especially that legacy IP does look more robust. > One idea I've had for this sort of scenario would be for the link to >operate as mostly an IPv6 over NBMA segment. The only multicasts on the >link are RAs, providing the necessary NBMA operation parameters. It of >course would require changes to clients and routers, but then again, so >would using DHCPv6 for what RAs are used for today. You can do this with no changes today. Block traffic between the hosts (similar to private vlan), advertise prefixes as off-link, send all the traffic via the router on the wired side, block all the inbound ND from hosts except for the RS and NS sent to solicited node address of the router + destined to the router. I tested this, it works like a charm - at least for the strawman browsing scenario. > > "Alternatively, in a very mobile environment and the RFC-compliant > > router, multicast solicited RAs might make a significant portion of > your traffic - which, due to a difference in modulation, etc. may eat > way more bandwidth than if they were sent unicast." > > The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a link >can't handle 1 multicast every few seconds, it's also past the point of >it's capacity (and as above, other multicast/broadcast would also be >contributing to exceeding link capacity.) Modulation. Your multicast packets may take in the most extreme case 54x time more airtime than a unicast. This means 54x more probability it will be dropped. Also, forget the home wireless with one AP. Now imagine 300-500 APs having to send these packets. You have 3 frequencies on 2.4Ghz spectrum that you can use. So remembering that the whole construct is 3D, you are *bound* to have some interference. So, it can be quite delicate in the most extreme cases. And again, I want the protocol to be deployable in the most extreme cases - especially when legacy IP survives them fine. Yes, not everyone will have them. But dismissing those cases just because they do not apply to one's environment is incorrect. And this is to me the whole point of the argument, which I would like to get back to, instead of trying to argue about the details: Yes, RA-only operation is *fantastic* for some circumstances. I love it myself and do it whenever I can because this allows me to avoid doing boring work. But I may be forced to do DHCPv6. For any of the reasons already present in the draft, pick one. And this means I am forced to do also RA, which is a pain. I think the large part of the tussle comes from the people wanting to make the functionality of the RA/DHCPv6 more symmetric and being told "no". And if we then tell them "Either use RA or no IPv6 for you" they say "fine, I choose no IPv6". And keep stacking on these NATs to support devices that "do not support IPv6" in that circumstances. I think in this discussion are again getting into the argument of "the best solution" instead of trying to collect the properties of the RA and DHCP. My position is that single best solution does not exist, because everyone's problems are slightly different. So, rather than preaching for everyone to adopt the single solution which is the best in one scenario and suboptimal in the other, we should be engineering a way to be able to apply different solutions in different circumstances without the overhead of double work. --a > > Regards, > Mark. > > > > > > > > > > > ----- Original Message ----- >> From: Andrew Yourtchenko >> To: v6ops@ietf.org >> Cc: >> Sent: Thursday, 28 November 2013 12:06 AM >> Subject: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >> >> Hello all, >> >> Finally I managed to comb a little bit and finally submit the doc that >> aims to compare RAs with DHCPv6 which emerged from the discussion on this >> list a few weeks ago. >> >> I'll be very happy to hear any comments, suggestions, flames, etc. >> >> --a >> >> > >> > --0-1852186906-1386327872=:68814-- From fred@cisco.com Fri Dec 6 10:29:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700311AE06F for ; Fri, 6 Dec 2013 10:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.502 X-Spam-Level: X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uhsHwyo-NPU for ; Fri, 6 Dec 2013 10:29:54 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0C31ADEB4 for ; Fri, 6 Dec 2013 10:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2689; q=dns/txt; s=iport; t=1386354590; x=1387564190; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QU6wDPIU7i1offa091bNdB92g0mO0e3SVFmDu8zMW7o=; b=B2G+3bQS1dG68cR1uRetGZr7iVdDigUmMrNel16lYVEvRC/6Cwo6ZEay b1/LxQIWw+17AK7HOUpQSVPUf0HjLRjJiRdx3GkOps8xIDlcc2WFFKoDM 8yzq75MmAMXYQEXoxyY+12umtD4gNg3d4XWTZRNNcFYCWnF3DMAiJ7Q59 o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAIcWolKtJV2Y/2dsb2JhbABZgwc4U7kEgSIWdIIlAQEBAwFlFAULAgEIRjIlAgQOBQkFh24GDcB1F48QB4MggRMDkDGBMYYykhODKYIq X-IronPort-AV: E=Sophos;i="4.93,842,1378857600"; d="asc'?scan'208";a="4895851" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 06 Dec 2013 18:29:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB6ITnnk028720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 18:29:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 12:29:49 -0600 From: "Fred Baker (fred)" To: Guillaume Leclanche Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt Thread-Index: AQHO8rEkQGKVeMPX5UyCxHg31HG0HQ== Date: Fri, 6 Dec 2013 18:29:47 +0000 Message-ID: <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_D72BEF13-A66B-4B83-9706-C85B804590B0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:29:57 -0000 --Apple-Mail=_D72BEF13-A66B-4B83-9706-C85B804590B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 6, 2013, at 7:51 AM, Guillaume Leclanche = wrote: > A lot of text was modified to make sure that the document could not be > mistaken for a recommendation. The filtering concept and examples are > not changed, as the authors have chosen to stick to describing the > documented practice. Wearing my "chair" hat. I'd like to understand the authors' guiding principle here. Is it=20 (a) to document the Swisscom experience,=20 (b) to "sell" an approach as having the attribute of being "balanced", = or=20 (c) to reflect the viewpoints of the working group? (a) would be well handled as an individual submission, whether to the = working group or in the independent stream, and should contain the word = "Swisscom" in the title. Cisco examples of this approach (and there are = ample other examples from Ericsson, Microsoft, and others) include http://www.ietf.org/rfc/rfc1613.txt http://www.ietf.org/rfc/rfc2105.txt http://www.ietf.org/rfc/rfc2281.txt http://www.ietf.org/rfc/rfc2341.txt http://www.ietf.org/rfc/rfc2741.txt http://www.ietf.org/rfc/rfc2892.txt http://www.ietf.org/rfc/rfc3488.txt http://www.ietf.org/rfc/rfc3924.txt http://www.ietf.org/rfc/rfc3954.txt http://www.ietf.org/rfc/rfc4332.txt http://www.ietf.org/rfc/rfc4463.txt http://www.ietf.org/rfc/rfc5171.txt http://www.ietf.org/rfc/rfc5517.txt http://www.ietf.org/rfc/rfc6037.txt http://www.ietf.org/rfc/rfc6218.txt http://www.ietf.org/rfc/rfc6656.txt http://www.ietf.org/rfc/rfc6759.txt http://www.ietf.org/rfc/rfc6812.txt (b) would similarly be an individual submission, either to the working = group or the independent stream. It would treat Swisscom as a proof = case, not a controlling consideration, working instead on the concept = that it wants to promote. (c) would require the authors to consider the working group to be in = control of the document, not the authors, and not Swisscom.=20 What is the guiding principle here? --Apple-Mail=_D72BEF13-A66B-4B83-9706-C85B804590B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSohecbjEdbHIsm0MRAuDWAKCvRUCee8B8ihE/mqmAozxOHcvBcQCeOu2e cZ2WYuU0hk8edkCFcZ4MiT8= =s3sN -----END PGP SIGNATURE----- --Apple-Mail=_D72BEF13-A66B-4B83-9706-C85B804590B0-- From guillaume@leclanche.net Fri Dec 6 11:11:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3D1AE046 for ; Fri, 6 Dec 2013 11:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVlsIc1XZg3l for ; Fri, 6 Dec 2013 11:11:40 -0800 (PST) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A8FF71AE133 for ; Fri, 6 Dec 2013 11:11:35 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id c14so1260167vea.37 for ; Fri, 06 Dec 2013 11:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leclanche.net; s=leclanche-net; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9rZxZQCwsiU0WrMbiFLsj7jBkBbH8hvUMKiVpPVspgc=; b=P+Q9IXqduUgmsY/ua/wRFttuZ56azMCdRKmW061vcBgTZjVdG5eiDBUs/lTlZFRP2p QJKV4ofhrE7N+vTWfLO8CLjlrDvDkpEhqm0XE9fsLw34hgt4DC17MFtm0hyp/BfV9Iji vfjNklhQcK7DIQAEkFvWuFZ61czYUUNK+hONI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9rZxZQCwsiU0WrMbiFLsj7jBkBbH8hvUMKiVpPVspgc=; b=hbyodiSQy7ZMBvCFTaElKd3nl1AXtT7RmnaRlhwAPyrRsQNQ9bSh7zRrkj/3ZDjNqp ei2r8Nf6EfPRRxBe/94GY/HMX/GbrTniIs3GivLptATXv5DbfmHvW0twTyrpv26BeDZY gsFqlZ+2yBvlf78aSNrh1VecJToLyMEHOTFyIK2D29A1h90G1QwPlgx4fNs+LRtkL3sG fWquSLR8cRATEcbMD7rcKfjrFjjStE3BQcrubAwCjAdE/Jx542ep67riPDJ4bfbnadDu hhMDDC3Oj5OtY0jw9opSWDjw0lyZ2wt2aeWkMa98ygb3upu4/V6DuYYemA1ugPCyTAEg qN6g== X-Gm-Message-State: ALoCoQmmugr1SBJrcmzDXLHqO7g/I3KoHuxr4WwxHhH1uMuakR5GzQ0bGl8e6XKPJe7i+Oo4AZNH X-Received: by 10.220.122.129 with SMTP id l1mr2179873vcr.48.1386357091401; Fri, 06 Dec 2013 11:11:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.24.200 with HTTP; Fri, 6 Dec 2013 11:10:51 -0800 (PST) X-Originating-IP: [2620:0:230:c000:3e97:eff:fe95:5451] In-Reply-To: <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> From: Guillaume Leclanche Date: Fri, 6 Dec 2013 14:10:51 -0500 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:11:47 -0000 2013/12/6 Fred Baker (fred) : > I'd like to understand the authors' guiding principle here. Is it > (a) to document the Swisscom experience, > (b) to "sell" an approach as having the attribute of being "balanced", or > (c) to reflect the viewpoints of the working group? Definitely (a). By adopting it, the WG showed interest in having this document saying "Hey look, this is done somewhere, v6ops thinks it's an interesting approach to CPE filtering.". Especially from people operating a network. How do you want to proceed ? Guillaume From sander@steffann.nl Fri Dec 6 11:23:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1409F1AD84D for ; Fri, 6 Dec 2013 11:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCwl2QHRGpzu for ; Fri, 6 Dec 2013 11:23:45 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 967871AE06F for ; Fri, 6 Dec 2013 11:23:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id CBC1F53; Fri, 6 Dec 2013 20:23:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKoAAl8fz767; Fri, 6 Dec 2013 20:23:35 +0100 (CET) Received: from [IPv6:2a00:8640:1::b978:860:b619:3f84] (unknown [IPv6:2a00:8640:1:0:b978:860:b619:3f84]) by mail.sintact.nl (Postfix) with ESMTPSA id E7E2151; Fri, 6 Dec 2013 20:23:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Sander Steffann In-Reply-To: Date: Fri, 6 Dec 2013 20:23:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <293288B1-36C0-4DD0-B533-6542861D33BA@steffann.nl> References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> To: Guillaume Leclanche X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:23:47 -0000 Hi, Op 6 dec. 2013, om 20:10 heeft Guillaume Leclanche = het volgende geschreven: > 2013/12/6 Fred Baker (fred) : >=20 >> I'd like to understand the authors' guiding principle here. Is it >> (a) to document the Swisscom experience, >> (b) to "sell" an approach as having the attribute of being = "balanced", or >> (c) to reflect the viewpoints of the working group? >=20 > Definitely (a). By adopting it, the WG showed interest in having this > document saying "Hey look, this is done somewhere, v6ops thinks it's > an interesting approach to CPE filtering.". Especially from people > operating a network. Indeed very interesting. Eventually I would like to see something like = this as (c), but that might be a bit to far for now. Cheers, Sander From brian.e.carpenter@gmail.com Fri Dec 6 12:47:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6985D1AE135 for ; Fri, 6 Dec 2013 12:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiBtSvkWwy5L for ; Fri, 6 Dec 2013 12:47:07 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 078D61AD8E1 for ; Fri, 6 Dec 2013 12:47:06 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id r10so1650478pdi.10 for ; Fri, 06 Dec 2013 12:47:03 -0800 (PST) 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=Hn6e/6dCDhFDBrrfUQklF78ApeiNiJd0tRkFNYePB4g=; b=OS73c97i7NrN7j6YE6aAobsY8DFT38QWUOAra9+5tvaj9wXyQrP+rOBJEN2JuNGbr6 fyp1SRtoMxTHrB+3NSshVr0732gadYxqiv9BFtmJ95G/Et9Iv00Ngwmx32p9xNY7HRaY YUs6eRqWNtX/uih/Q3nHwB4DAB2jbic6cnPvT9yCOvP0e8q3n8E9FCndgVOQi+pdrn9Z KSG6OmPPtET1q7h/bJ4d9YeMtcJ/4eLcMbDgYtH1/53hAE9P2o+Ul7t3NfiXOiK6jvYT 8prIWOMoC6eUaCslD7glfV02kSmoL5YiLSIMu1wHbz2k2oI/1Nlqiak33iERatR0s0nW WOag== X-Received: by 10.68.240.36 with SMTP id vx4mr6400199pbc.140.1386362823338; Fri, 06 Dec 2013 12:47:03 -0800 (PST) Received: from [192.168.178.20] (243.194.69.111.dynamic.snap.net.nz. [111.69.194.243]) by mx.google.com with ESMTPSA id er3sm153689890pbb.40.2013.12.06.12.47.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 12:47:02 -0800 (PST) Message-ID: <52A237D1.2040009@gmail.com> Date: Sat, 07 Dec 2013 09:47:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sander Steffann References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> <293288B1-36C0-4DD0-B533-6542861D33BA@steffann.nl> In-Reply-To: <293288B1-36C0-4DD0-B533-6542861D33BA@steffann.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:47:08 -0000 On 07/12/2013 08:23, Sander Steffann wrote: > Hi, > > Op 6 dec. 2013, om 20:10 heeft Guillaume Leclanche het volgende geschreven: > >> 2013/12/6 Fred Baker (fred) : >> >>> I'd like to understand the authors' guiding principle here. Is it >>> (a) to document the Swisscom experience, >>> (b) to "sell" an approach as having the attribute of being "balanced", or >>> (c) to reflect the viewpoints of the working group? >> Definitely (a). By adopting it, the WG showed interest in having this >> document saying "Hey look, this is done somewhere, v6ops thinks it's >> an interesting approach to CPE filtering.". Especially from people >> operating a network. > > Indeed very interesting. Eventually I would like to see something like this as (c), but that might be a bit to far for now. Sander, from the experience that the authors of RFC 4864 in getting anything close to rough consensus, I'd say that the chances of achieving (c) are very low, since there's a wide range of opinion (due to a wide range of requirements). I think (a) is a wise path to get this useful document out in public. This really is a case where the market makes a choice. Brian From sander@steffann.nl Fri Dec 6 12:52:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E195D1AE01A for ; Fri, 6 Dec 2013 12:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5SAzxaQbzYt for ; Fri, 6 Dec 2013 12:52:46 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5B31AD957 for ; Fri, 6 Dec 2013 12:52:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 71EAB51; Fri, 6 Dec 2013 21:52:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pISwi0bcK-s0; Fri, 6 Dec 2013 21:52:39 +0100 (CET) Received: from [37.77.56.82] (temp82.10ww.steffann.nl [37.77.56.82]) by mail.sintact.nl (Postfix) with ESMTPSA id 8A00D46; Fri, 6 Dec 2013 21:52:38 +0100 (CET) References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> <293288B1-36C0-4DD0-B533-6542861D33BA@steffann.nl> <52A237D1.2040009@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52A237D1.2040009@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B554a) From: Sander Steffann Date: Fri, 6 Dec 2013 21:52:38 +0100 To: Brian E Carpenter Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:52:47 -0000 Hi Brian, > Sander, from the experience that the authors of RFC 4864 in getting > anything close to rough consensus, I'd say that the chances of > achieving (c) are very low, since there's a wide range of opinion > (due to a wide range of requirements). >=20 > I think (a) is a wise path to get this useful document out > in public. This really is a case where the market makes > a choice. Indeed. (a) is the wisest now. If the market chooses this approach then (c) m= ight happen in the future. Cheers, Sander From fred@cisco.com Fri Dec 6 14:33:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C159C1ADFB8 for ; Fri, 6 Dec 2013 14:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcFxxqoQzbzW for ; Fri, 6 Dec 2013 14:33:58 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 72D901AD9AE for ; Fri, 6 Dec 2013 14:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1592; q=dns/txt; s=iport; t=1386369235; x=1387578835; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ngob3NuWqrwC5ok+6wxpXvf0IQwDsNOQj9BoNV4xDVM=; b=PYT+EYZB9nuGea2Fwqel9oxcBKwHXbQezjeekh394UM1S37C0/eIkMJ0 YzURNVRq2JY6SjkBrOLCap2ajzvNEmbp1+QlDOMOpG7iGr8sHHn1Ntd// A1YOpRKJBOWR4mUqR1gEjkqyu+qJKY0uG9CrF1MRytIMhV+GV294bwoSE o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFRQolKtJV2d/2dsb2JhbABZgweBC7kMgSMWdIIlAQEBAwFlFBACAQhGMiUCBA4FDoduBsEBF48QB4MggRMDkDGBMYYykhODKYIq X-IronPort-AV: E=Sophos;i="4.93,842,1378857600"; d="asc'?scan'208";a="289964878" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 06 Dec 2013 22:33:54 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB6MXsLI014690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 22:33:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 16:33:54 -0600 From: "Fred Baker (fred)" To: Guillaume Leclanche Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt Thread-Index: AQHO8tM+mjeN4esHk0S5Sq68CojxVw== Date: Fri, 6 Dec 2013 22:33:53 +0000 Message-ID: <044CE3AE-81CE-40DD-8E70-B6A067F4E9E5@cisco.com> References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_DC5882A9-EFDE-4740-BBF0-60E5360C9074"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 22:33:59 -0000 --Apple-Mail=_DC5882A9-EFDE-4740-BBF0-60E5360C9074 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 6, 2013, at 11:10 AM, Guillaume Leclanche = wrote: >> I'd like to understand the authors' guiding principle here. Is it >> (a) to document the Swisscom experience, >> (b) to "sell" an approach as having the attribute of being = "balanced", or >> (c) to reflect the viewpoints of the working group? >=20 > Definitely (a). By adopting it, the WG showed interest in having this > document saying "Hey look, this is done somewhere, v6ops thinks it's > an interesting approach to CPE filtering.". Especially from people > operating a network. My problem is that (a) isn't a working group document; it's an = experience report from Swisscom. Using Swisscom's experience as an = example of the working group's outcome is fine, but then the document = has to reflect the working group's viewpoint. Swisscom can be an = example, but not the controlling interest. --Apple-Mail=_DC5882A9-EFDE-4740-BBF0-60E5360C9074 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSolDPbjEdbHIsm0MRAnLlAJ4zCyxNt0CWiscXG7Jw4ym1EMHbFgCg+xyd /09RSB++GexHaDRMo8ukMlo= =kTGh -----END PGP SIGNATURE----- --Apple-Mail=_DC5882A9-EFDE-4740-BBF0-60E5360C9074-- From markzzzsmith@yahoo.com.au Fri Dec 6 17:01:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEF61AE13A for ; Fri, 6 Dec 2013 17:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.201 X-Spam-Level: ** X-Spam-Status: No, score=2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fGo3v0UTIRG for ; Fri, 6 Dec 2013 17:01:27 -0800 (PST) Received: from nm39-vm5.bullet.mail.bf1.yahoo.com (nm39-vm5.bullet.mail.bf1.yahoo.com [72.30.239.149]) by ietfa.amsl.com (Postfix) with SMTP id B8BCE1ADF7F for ; Fri, 6 Dec 2013 17:01:26 -0800 (PST) Received: from [98.139.212.152] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 01:01:22 -0000 Received: from [98.139.212.227] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 01:01:22 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 01:01:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 590095.39177.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 38963 invoked by uid 60001); 7 Dec 2013 01:01:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1386378082; bh=ss/n+lhgOsHsU0W438i/p1Jk1UNkA5+0ev2+2Y5On7Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sCSknMZnzm2YZkz7s9NPSHq4TsPv7Q3yhC/GCxnUBJwh2s9LsN+VpazqOga29vtfGCJs2pooyvckrMXT2eqis8ri8fS13odtvthzfo6f4JDHf54M+E3Mhc2Wb/wWEoSpMGVQJdmzfj2BoFPCN5JpES/9tfhKNb40Gttb5490EdI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iv54Qh6BoiXlHRyLFa2WcpiUZHMG2HyBo6zBsBUci1t4FYyqmHbXb9UCP0+iFPmTp8HzIGPFx8lhvWk5B/oa28dSaSMdxydQc+sUAaMvdPCka5Q4171a9YoM5GZylCWHKv0Dm2o0Y1UxXaaoZwEnziAREO7i7LgOAzS6Qnbchck=; X-YMail-OSG: ToNjL8kVM1mwdxwJF4EG6RVKpbyFuvXeJ1pDVxz0551N9UK yK59XrNit2vNoIim0nEMYwNoJpjlZjjh4E.EyNA_SXKQsTrX79odCqTUv45O kD0bix95wBmIx4onSZSKKDFvNeanjkfUTNjglxMu8Z.im5qkjN1FJQp7QXQu N.WTfRieBGQ2wN81s3JDajnLA4Thr0XMJYID_3WxNqT1lhSNv4mgzuA1dxj. SlUlmyLJmg7m2A4.FRQsas8fH8gzCcpl1FI6xIfFO2fFVX1GWMgVWPfIGfur O.GoYTZz_q.kg_ZFq3.Piu_CbfvVX4XqVGEB4jK1PkJ8dsoZYTuRDa_Mf6Ww eqTiIrMeEvmU2yIItsnVfNjHIKPw61h5ehEaaSTJNdn8s0hxVOIwg1jUcoqS RiXn.SsWu82Fy22WQjsP3WRP.LwJ48rYx3W9l8KmMOOlHv4KbgvFOZG4No4E r_S4m1Pu1HM.w373IHMxg3fzrxMpHnecfO.acuASnB_35utEMikywmIvTnDO qX1AW6Dz.2hr85dy0WmxTvqCeErh6HFEDR8H6W2pr2wgow06L3z.mdyj0iNo .zV8nSshjUhJQp4o3iuo- Received: from [150.101.221.237] by web161901.mail.bf1.yahoo.com via HTTP; Fri, 06 Dec 2013 17:01:22 PST X-Rocket-MIMEInfo: 002.001, Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFNhdHVyZGF5LCA3IERlY2VtYmVyIDIwMTMgMzozNCBBTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW91cnRjaGVua28tcmEtZGhjcHY2LWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> Date: Fri, 6 Dec 2013 17:01:22 -0800 (PST) From: Mark ZZZ Smith To: Andrew Yourtchenko In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 01:01:29 -0000 =0A----- Original Message -----=0A> From: Andrew Yourtchenko =0A> To: Mark ZZZ Smith =0A> Cc: "v6ops@ie= tf.org" =0A> Sent: Saturday, 7 December 2013 3:34 AM=0A> Su= bject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6= -comparison-00.txt (fwd)=0A> =0A> Hi Mark,=0A> =0A> On Thu, 5 Dec 2013, Mar= k ZZZ Smith wrote:=0A> =0A>>=A0=A0Hi,=0A>> =0A>>=A0=A0Some criticisms/comme= nts/questions on these pieces of text relating to =0A> layer 2/wifi multica= st reliablity:=0A>> =0A>>=A0=A0"This is where the peer-to-peer, acknowledge= d nature of DHCPv6 may be=0A>>=A0=A0beneficial - on a crowded large-scale W= iFi, without special tricks to =0A>> ensure the reliable delivery of multic= ast packets, you simply will not =0A>> get the SLAAC working because the mu= lticast RAs will get crunched by the =0A>> interference."=0A>>=A0=A0I'd thi= nk that if multicast is unreliable enough to cause RAs to fail =0A>> to be = delivered often enough, then anything which relies on multicast =0A>> traff= ic is also likely to fail, which would include neighbor discovery. =0A>> So= regardless of if RAs were replaced with DHCPv6, the link is not going =0A>= > to provide reliable IPv6 operation, because IPv6=A0addresses cannot be = =0A>> reliably resolved to layer 2 addresses.=0A>> =0A>>=A0=A0MLD would pro= bably fail too, so any routed multicast applications, even =0A>> low bandwi= dth ones, wouldn't work either, as would MLD snooping based =0A>> layer 2 f= orwarding optimisation.=0A>> =0A>>=A0=A0DHCPv6 uses multicast for DHCPv6 se= rver/relay discovery, so that will =0A> probably be unreliable as well.=0A>= > =0A>>=A0=A0I don't think broadcasts on wifi are reliable, so IPv4 ARP wou= ld be =0A> failing too.=0A>> =0A>>=A0=A0So if RAs are failing because of no= t reliable enough multicast then =0A>> that is just one symptom of the link= being overloaded, and there will be =0A>> others.=0A> =0A> I think I captu= re several points here, tell me if I get them correctly:=0A> =0A> 1) There = are other protocols that use multicast that will fail.=0A=0AYes.=A0=0A=0A> = 2) Fix your link.=0A> =0A> for (1): RA is probably the only one that does n= ot incorporate a robust =0A> retransmit mechanism.=0A>=A0=0A=0AIn the case = of multicast RAs there are two independent reliability mechanisms used, one= router side, one host side.=0A=0AFirstly, the router lifetime in the RA is= to be set to AdvDefaultLifetime or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1),= meaning that for a host to lose knowledge of a router it has to miss 3 uns= olicited multicast RAs in a row.=0A=0ASecondly, hosts retransmit their RSes= multiple times (RFC4861, 6.3.7).=0A=0AI'd argue that DHCPv6, neighbor disc= overy and MLD are less robust, as they only implement the second mechanism.= For DHCPv6, neighbor discovery and MLD to be as robust as RAs, the DHCPv6 = server and the hosts would have to also issue periodically unsolicited anno= uncements of themselves so that other hosts and routers don't have to solic= it for them, unless they have no existing knowledge of them.=0A=0A(Should w= e add the ES-IS neighbor discovery model to IPv6 ND to make it more robust?= ES-IS has hosts periodically multicast their presence to the link's router= s, routers periodically multicast their presence to the hosts, hosts defaul= t to sending to their routers for all destinations, then routers sends a re= directs to a host when the destination host is on the same link.).=0A=0A=0A= > for (2): It's great if you can, but I'd like to have protocol work in =0A= > all =0A> conditions.=0A=0AThat sound to me like an assertion that DHCPv6 = is going to work in all conditions. Given that DHCPv6 server discovery is l= ess reliable than RAs (because of the lack of unsolicited DHCPv6 server adv= ertisements), how is moving RA functions into DHCPv6 going to make DHCPv6 m= ore reliable than RAs?=0A=0A> Especially that legacy IP does look more robu= st.=0A=0A>=A0=0A=0ASo I'm curious why legacy IP is supposedly more robust? = IPv4 uses broadcasts for ARP and DHCP server discovery. On these links wher= e IPv4 "looks more robust" than IPv6, are broadcasts provided more reliable= delivery than multicasts, in particular as broadcasts must be flooded to a= ll hosts, where as multicasts can have their flooding scope limited using M= LD snooping?=0A=0A=0A> =0A>>=A0=A0One idea I've had for this sort of scenar= io would be for the link to =0A>> operate as mostly an IPv6 over NBMA segme= nt. The only multicasts on the =0A>> link are RAs, providing the necessary = NBMA operation parameters. It of =0A>> course would require changes to clie= nts and routers, but then again, so =0A>> would using DHCPv6 for what RAs a= re used for today.=0A> =0A> You can do this with no changes today.=0A> =0A>= Block traffic between the hosts (similar to private vlan), advertise =0A> = prefixes as off-link, send all the traffic via the router on the wired =0A>= side, block all the inbound ND from hosts except for the RS and =0A> NS se= nt to solicited node address of the router + destined to the router.=0A> = =0A> I tested this, it works like a charm - at least for the strawman brows= ing =0A> scenario.=0A>=A0=0A=0ARight, and doing that would solve the multic= ast capacity exhaustion problems that would effect RA multicasts (and DHCPv= 6, ND and MLD multicasts), because it is a more extreme case of constrainin= g where multicasts are sent than MLD snooping.=0A=0AMy Broadcast Multi-Acce= ss (BMA) link operating as NBMA suggestion wouldn't require both having ava= ilable and enabling any link-layer special features to achieve the goal of = significantly reducing multicast traffic.=A0=0A=0A(Thinking about it, the r= ecent Efficient ND proposal is perhaps a special case of operating a BMA li= nk as an NBMA link for the Neighbor Discovery protocol. I'm starting to won= der if it might be better to just adopt this complete NBMA model over a BMA= link and eliminate all link-layer multicasts (ND, DHCPv6, MLD), except RAs= to announce the BMA link is operating in NBMA mode. The only multicasts wo= uld be unsolicited RAs, which, for a single router, could be only once ever= y 30 minutes (15 minutes for two routers). I'd think that sort of interval = would be adequate to address the concerns of multicasts consuming mobile de= vice battery life.)=0A=0A=0A>> =0A>>=A0=A0"Alternatively, in a very mobile = environment and the RFC-compliant=0A>> =0A>>=A0=A0router, multicast solicit= ed RAs might make a significant portion of =0A>>=A0=A0your traffic - which,= due to a difference in modulation, etc.=A0 may eat =0A>>=A0=A0way more ban= dwidth than if they were sent unicast."=0A>> =0A>>=A0=A0The MIN_DELAY_BETWE= EN_RAS in RFC4861 is 3 seconds. I'd think if a link =0A>> can't handle 1 mu= lticast every few seconds, it's also past the point =0A> of =0A>> it's capa= city (and as above, other multicast/broadcast would also be =0A>> contribut= ing to exceeding link capacity.)=0A> =0A> Modulation. Your multicast packet= s may take in the most extreme case 54x =0A> time more airtime than a unica= st. This means 54x more probability it will =0A> be dropped. Also, forget t= he home wireless with one AP. Now imagine =0A> 300-500 APs having to send t= hese packets. You have 3 frequencies on 2.4Ghz =0A> spectrum that you can u= se. So remembering that the whole construct is 3D, =0A> you are *bound* to = have some interference.=0A>=A0=0A=0AAre all of those 300-500 APs in a singl= e broadcast/multicast domain i.e., one large link? That's convenient, but i= f multicasts/broadcasts aren't reliable enough, that suggests the link capa= city is exhausted. Dividing the link up using routers to reduce multicast/b= roadcasts is and has been the common solution since broadcast multiaccess l= inks were invented (which I think would be since around late 1970s when Eth= ernet was invented).=0A=0AMoving to an NBMA model by effectively modelling = the BMA link as a full mesh of virtual point-to-point links would probably = be an alternative method of overcoming multicast/broadcast capacity limitat= ions.=0A=0A> So, it can be quite delicate in the most extreme cases.=0A> = =0A> And again, I want the protocol to be deployable in the most extreme ca= ses =0A> - especially when legacy IP survives them fine.=0A>=A0=0A=0AHow do= es it? Legacy IP uses broadcasts.=A0=0A=0A> Yes, not everyone will have the= m.=0A> =0A> But dismissing those cases just because they do not apply to on= e's=0A> environment is incorrect.=0A> =0A> And this is to me the whole poin= t of the argument, which I would like to =0A> get back to, instead of tryin= g to argue about the details:=0A> =0A> Yes, RA-only operation is *fantastic= * for some circumstances. I love it =0A> myself and do it whenever I can be= cause this allows me to avoid doing =0A> boring work.=0A> =0A> But I may be= forced to do DHCPv6. For any of the reasons already present =0A> in the dr= aft, pick one. And this means I am forced to do also RA, which =0A> is a pa= in.=0A>=A0=0A=0ASo the objections I have are,=0A=0A- I don't see how anythi= ng in DHCPv6 makes it dramatically more reliable than RAs, given that it to= o uses multicasts for DHCPv6 server discovery. Adding RA functions into DHC= Pv6 is described or asserted to be the panacea to all issues that RAs could= suffer from, yet analysis shows it isn't.=0A=0A- I think it would be bette= r to incrementally tune and optimise the existing designed, standardised, c= ode developed, code debugged and widely deployed mechanism (RAs) to overcom= e corner cases, and/or to adopt past developed methods such as IPv6 over NB= MA, than to spend the next 5 to 10 years waiting for the design, standardis= ation, code development, code debugging and widespread deployment of RA fun= ctions to be incorporated into DHCPv6, and then also have to develop method= s of conflict resolution when RAs and DHCPv6 options disagree (because they= will, unless you don't plan to transition to DHCPv6 only until DHCPv6 RA f= unctions are ubiquitous. RAs and DHCPv6 RA functions will have to co-exist = on a link for many years if you can't demand or guarantee DHCPv6 RA functio= nality from the host implementations.)=0A=0A- Using DHCPv6 for RA functiona= lity won't eliminate one of the supposed causes of RA unreliability - multi= cast unreliability. All of DHCPv6, neighbor discovery and MLD would have to= be made more robust against multicast unreliability to truly solve that pr= oblem.=0A=0A- I'm for a single method that works adequately. DHCPv6 with RA= options would probably qualify if we didn't already have a existing method= . Existing methods that work are always better than non-existent ones that = need to be developed, tested and ubiquitously deployed before they become s= ignificantly useful and can be assumed to be available.=0A=0A=0A> I think t= he large part of the tussle comes from the people wanting to =0A> make the = functionality of the RA/DHCPv6 more symmetric and being told =0A> "no".=0A>= =A0=0A=0AThe thing they need to demonstrate is that the costs of deploying = a new and second mechanism that is near functionally equivalent to the firs= t is worth the benefits. Given that the costs of developing and deploying R= As has already been paid, I think the benefits of using DHCPv6 for RA funct= ions have to be very significant=A0before the price should be paid. The ben= efits of DHCPv6 for RA functions now needs to be compelling. I don't think = they are, otherwise I'd be quite happy to advocate for DHCPv6 for RA functi= ons.=0A=0A=0A> And if we then tell them "Either use RA or no IPv6 for you" = they say=A0=0A=0A> "fine, I choose no IPv6". And keep stacking on these NAT= s to support =0A> devices that "do not support IPv6" in that circumstances.= =0A>=A0=0A=0AI don't think RAs are the single reason some people are resist= ing deploying IPv6 at all. I think some people are resisting deploying IPv6= because it needs to do one or both of two things for them - solve a forese= eable problem that will effect them, or provide a tangible benefit. If it w= on't do either of those things, then they don't currently see any value fro= m the effort involved. What are foreseeable problems or tangible benefits i= s completely up to the perspective of the decision maker. Eventually they'l= l see value in it, and deploy it. In some cases, some people who could depl= oy IPv6 may never see any value in deploying it, so they never will.=0A=0AT= here is no single answer to why people might resist deploying IPv6, no sing= le solution, and things that motivate people to deploy or not IPv6 may have= nothing to do with how IPv6 itself works.=0A=0A=0A=0A> I think in this dis= cussion are again getting into the argument of "the =0A> best solution" ins= tead of trying to collect the properties of the RA and =0A> DHCP.=0A>=A0=0A= > My position is that single best solution does not exist, because=A0=0A=0A= > everyone's problems are slightly different. So, rather than preaching for= =0A> everyone to adopt the single solution which is the best in one scenar= io =0A> and suboptimal in the other, we should be engineering a way to be a= ble to =0A> apply different solutions in different circumstances without th= e =0A> overhead of double work.=0A>=A0=0A=0AA single solution that solves m= ost cases is better than two different, near functionally equivalent soluti= ons that solve the same cases. Multiple near-equivalent solutions create mo= re code, more bugs and then require conflict resolution mechanisms, creatin= g even more code and more bugs, with very little actual benefit.=0A=0AThere= are multiple ways of solving the neighbor discovery/router discovery/host = parameter configuration problem (read Radia Perlman's "Interconnections" bo= ok as a starting point, and then perhaps "Inside Appletalk", and also look = into Novell's IPX and Network Directory Services.). They all have different= trade-offs, but fundamentally the trade-offs aren't significantly differen= t or compelling. Yet because there are multiple methods to solve these prob= lems, does that justify implementing all of them because they each have som= e minor benefits over the others, that different people might prefer?=0A=0A= Regards,=0AMark. From volz@cisco.com Fri Dec 6 17:26:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D5D1AE168 for ; Fri, 6 Dec 2013 17:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4E2sWYB6Dyw for ; Fri, 6 Dec 2013 17:25:58 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id D995C1AE067 for ; Fri, 6 Dec 2013 17:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15152; q=dns/txt; s=iport; t=1386379554; x=1387589154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4gO5RkTuExPZoD0IO4KhmrNZk7a4g35j/ttOimmjDjo=; b=PPdKoesePA/ntSbpEsusYxkABd8Phl13dAW1LfOIw/+wpGvrfrlleRgK 9pAXTWWRnTbqayW4c5btC9wEAzDGYw5qiUUSAitoB5toqtqqnRbxm2rKG JPdVnvdcVhPeyt3eqH9n2l0w4muJIENkwHNvbPxR4hNazWB1BgFzTOjp0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogSAMx3olKtJXG9/2dsb2JhbABZgXECAYETOFO5D4EfFnSCJQEBAQMBAQEBawkCBQcEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCBECh1UDCQYNsVWPFxMEjH2BKxAnMQcGgxqBEwOJCo0ljj+FOYFrgT6BaEI X-IronPort-AV: E=Sophos;i="4.93,843,1378857600"; d="scan'208";a="4990342" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 07 Dec 2013 01:25:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB71PrMk015717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Dec 2013 01:25:53 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 19:25:52 -0600 From: "Bernie Volz (volz)" To: Mark ZZZ Smith , "Andrew Yourtchenko (ayourtch)" Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO8ufo8sOhdw9Xj0eSkw7nY3E0jZpH73mQ Date: Sat, 7 Dec 2013 01:25:51 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> In-Reply-To: <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.216] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 01:26:03 -0000 Mark: The difference between DHCPv6 and RA multicast is the direction. DHCPv6 multicast is client to server (or relay). This has far fewer problem= s in some networks because the first hop is typically on the wired portion = of the network (and the destination multicast address is usually just joine= d by a few devices (relays and servers) - not all). RA multicast is router to client(s). This has problems in distributing the = traffic out to all of the clients over some networks. - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith Sent: Friday, December 06, 2013 8:01 PM To: Andrew Yourtchenko (ayourtch) Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcp= v6-comparison-00.txt (fwd) ----- Original Message ----- > From: Andrew Yourtchenko > To: Mark ZZZ Smith > Cc: "v6ops@ietf.org" > Sent: Saturday, 7 December 2013 3:34 AM > Subject: Re: [v6ops] New Version Notification for=20 > draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >=20 > Hi Mark, >=20 > On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: >=20 >>=A0=A0Hi, >>=20 >>=A0=A0Some criticisms/comments/questions on these pieces of text relating= =20 >>to > layer 2/wifi multicast reliablity: >>=20 >>=A0=A0"This is where the peer-to-peer, acknowledged nature of DHCPv6 may= =20 >>be >>=A0=A0beneficial - on a crowded large-scale WiFi, without special tricks= =20 >>to ensure the reliable delivery of multicast packets, you simply will=20 >>not get the SLAAC working because the multicast RAs will get crunched=20 >>by the interference." >>=A0=A0I'd think that if multicast is unreliable enough to cause RAs to=20 >>fail to be delivered often enough, then anything which relies on=20 >>multicast traffic is also likely to fail, which would include neighbor d= iscovery. >> So regardless of if RAs were replaced with DHCPv6, the link is not=20 >>going to provide reliable IPv6 operation, because IPv6=A0addresses=20 >>cannot be reliably resolved to layer 2 addresses. >>=20 >>=A0=A0MLD would probably fail too, so any routed multicast applications,= =20 >>even low bandwidth ones, wouldn't work either, as would MLD snooping=20 >>based layer 2 forwarding optimisation. >>=20 >>=A0=A0DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that=20 >>will > probably be unreliable as well. >>=20 >>=A0=A0I don't think broadcasts on wifi are reliable, so IPv4 ARP would be > failing too. >>=20 >>=A0=A0So if RAs are failing because of not reliable enough multicast then= =20 >>that is just one symptom of the link being overloaded, and there will=20 >>be others. >=20 > I think I capture several points here, tell me if I get them correctly: >=20 > 1) There are other protocols that use multicast that will fail. Yes.=A0 > 2) Fix your link. >=20 > for (1): RA is probably the only one that does not incorporate a=20 > robust retransmit mechanism. >=A0 In the case of multicast RAs there are two independent reliability mechanis= ms used, one router side, one host side. Firstly, the router lifetime in the RA is to be set to AdvDefaultLifetime o= r 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to lose k= nowledge of a router it has to miss 3 unsolicited multicast RAs in a row. Secondly, hosts retransmit their RSes multiple times (RFC4861, 6.3.7). I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as they = only implement the second mechanism. For DHCPv6, neighbor discovery and MLD= to be as robust as RAs, the DHCPv6 server and the hosts would have to also= issue periodically unsolicited announcements of themselves so that other h= osts and routers don't have to solicit for them, unless they have no existi= ng knowledge of them. (Should we add the ES-IS neighbor discovery model to IPv6 ND to make it mor= e robust? ES-IS has hosts periodically multicast their presence to the link= 's routers, routers periodically multicast their presence to the hosts, hos= ts default to sending to their routers for all destinations, then routers s= ends a redirects to a host when the destination host is on the same link.). > for (2): It's great if you can, but I'd like to have protocol work in=20 > all conditions. That sound to me like an assertion that DHCPv6 is going to work in all cond= itions. Given that DHCPv6 server discovery is less reliable than RAs (becau= se of the lack of unsolicited DHCPv6 server advertisements), how is moving = RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs? > Especially that legacy IP does look more robust. >=A0 So I'm curious why legacy IP is supposedly more robust? IPv4 uses broadcast= s for ARP and DHCP server discovery. On these links where IPv4 "looks more = robust" than IPv6, are broadcasts provided more reliable delivery than mult= icasts, in particular as broadcasts must be flooded to all hosts, where as = multicasts can have their flooding scope limited using MLD snooping? >=20 >>=A0=A0One idea I've had for this sort of scenario would be for the link t= o =20 >>operate as mostly an IPv6 over NBMA segment. The only multicasts on=20 >>the link are RAs, providing the necessary NBMA operation parameters.=20 >>It of course would require changes to clients and routers, but then=20 >>again, so would using DHCPv6 for what RAs are used for today. >=20 > You can do this with no changes today. >=20 > Block traffic between the hosts (similar to private vlan), advertise=20 > prefixes as off-link, send all the traffic via the router on the wired=20 > side, block all the inbound ND from hosts except for the RS and NS=20 > sent to solicited node address of the router + destined to the router. >=20 > I tested this, it works like a charm - at least for the strawman=20 > browsing scenario. >=A0 Right, and doing that would solve the multicast capacity exhaustion problem= s that would effect RA multicasts (and DHCPv6, ND and MLD multicasts), beca= use it is a more extreme case of constraining where multicasts are sent tha= n MLD snooping. My Broadcast Multi-Access (BMA) link operating as NBMA suggestion wouldn't = require both having available and enabling any link-layer special features = to achieve the goal of significantly reducing multicast traffic.=A0 (Thinking about it, the recent Efficient ND proposal is perhaps a special c= ase of operating a BMA link as an NBMA link for the Neighbor Discovery prot= ocol. I'm starting to wonder if it might be better to just adopt this compl= ete NBMA model over a BMA link and eliminate all link-layer multicasts (ND,= DHCPv6, MLD), except RAs to announce the BMA link is operating in NBMA mod= e. The only multicasts would be unsolicited RAs, which, for a single router= , could be only once every 30 minutes (15 minutes for two routers). I'd thi= nk that sort of interval would be adequate to address the concerns of multi= casts consuming mobile device battery life.) >>=20 >>=A0=A0"Alternatively, in a very mobile environment and the RFC-compliant >>=20 >>=A0=A0router, multicast solicited RAs might make a significant portion of >>=A0=A0your traffic - which, due to a difference in modulation, etc.=A0 ma= y=20 >>eat >>=A0=A0way more bandwidth than if they were sent unicast." >>=20 >>=A0=A0The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a=20 >>link can't handle 1 multicast every few seconds, it's also past the=20 >>point > of >> it's capacity (and as above, other multicast/broadcast would also be=20 >> contributing to exceeding link capacity.) >=20 > Modulation. Your multicast packets may take in the most extreme case=20 > 54x time more airtime than a unicast. This means 54x more probability=20 > it will be dropped. Also, forget the home wireless with one AP. Now=20 > imagine > 300-500 APs having to send these packets. You have 3 frequencies on=20 > 2.4Ghz spectrum that you can use. So remembering that the whole=20 > construct is 3D, you are *bound* to have some interference. >=A0 Are all of those 300-500 APs in a single broadcast/multicast domain i.e., o= ne large link? That's convenient, but if multicasts/broadcasts aren't relia= ble enough, that suggests the link capacity is exhausted. Dividing the link= up using routers to reduce multicast/broadcasts is and has been the common= solution since broadcast multiaccess links were invented (which I think wo= uld be since around late 1970s when Ethernet was invented). Moving to an NBMA model by effectively modelling the BMA link as a full mes= h of virtual point-to-point links would probably be an alternative method o= f overcoming multicast/broadcast capacity limitations. > So, it can be quite delicate in the most extreme cases. >=20 > And again, I want the protocol to be deployable in the most extreme=20 > cases > - especially when legacy IP survives them fine. >=A0 How does it? Legacy IP uses broadcasts.=A0 > Yes, not everyone will have them. >=20 > But dismissing those cases just because they do not apply to one's=20 > environment is incorrect. >=20 > And this is to me the whole point of the argument, which I would like=20 > to get back to, instead of trying to argue about the details: >=20 > Yes, RA-only operation is *fantastic* for some circumstances. I love=20 > it myself and do it whenever I can because this allows me to avoid=20 > doing boring work. >=20 > But I may be forced to do DHCPv6. For any of the reasons already=20 > present in the draft, pick one. And this means I am forced to do also=20 > RA, which is a pain. >=A0 So the objections I have are, - I don't see how anything in DHCPv6 makes it dramatically more reliable th= an RAs, given that it too uses multicasts for DHCPv6 server discovery. Addi= ng RA functions into DHCPv6 is described or asserted to be the panacea to a= ll issues that RAs could suffer from, yet analysis shows it isn't. - I think it would be better to incrementally tune and optimise the existin= g designed, standardised, code developed, code debugged and widely deployed= mechanism (RAs) to overcome corner cases, and/or to adopt past developed m= ethods such as IPv6 over NBMA, than to spend the next 5 to 10 years waiting= for the design, standardisation, code development, code debugging and wide= spread deployment of RA functions to be incorporated into DHCPv6, and then = also have to develop methods of conflict resolution when RAs and DHCPv6 opt= ions disagree (because they will, unless you don't plan to transition to DH= CPv6 only until DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA funct= ions will have to co-exist on a link for many years if you can't demand or = guarantee DHCPv6 RA functionality from the host implementations.) - Using DHCPv6 for RA functionality won't eliminate one of the supposed cau= ses of RA unreliability - multicast unreliability. All of DHCPv6, neighbor = discovery and MLD would have to be made more robust against multicast unrel= iability to truly solve that problem. - I'm for a single method that works adequately. DHCPv6 with RA options wou= ld probably qualify if we didn't already have a existing method. Existing m= ethods that work are always better than non-existent ones that need to be d= eveloped, tested and ubiquitously deployed before they become significantly= useful and can be assumed to be available. > I think the large part of the tussle comes from the people wanting to=20 > make the functionality of the RA/DHCPv6 more symmetric and being told=20 > "no". >=A0 The thing they need to demonstrate is that the costs of deploying a new and= second mechanism that is near functionally equivalent to the first is wort= h the benefits. Given that the costs of developing and deploying RAs has al= ready been paid, I think the benefits of using DHCPv6 for RA functions have= to be very significant=A0before the price should be paid. The benefits of = DHCPv6 for RA functions now needs to be compelling. I don't think they are,= otherwise I'd be quite happy to advocate for DHCPv6 for RA functions. > And if we then tell them "Either use RA or no IPv6 for you" they say > "fine, I choose no IPv6". And keep stacking on these NATs to support=20 > devices that "do not support IPv6" in that circumstances. >=A0 I don't think RAs are the single reason some people are resisting deploying= IPv6 at all. I think some people are resisting deploying IPv6 because it n= eeds to do one or both of two things for them - solve a foreseeable problem= that will effect them, or provide a tangible benefit. If it won't do eithe= r of those things, then they don't currently see any value from the effort = involved. What are foreseeable problems or tangible benefits is completely = up to the perspective of the decision maker. Eventually they'll see value i= n it, and deploy it. In some cases, some people who could deploy IPv6 may n= ever see any value in deploying it, so they never will. There is no single answer to why people might resist deploying IPv6, no sin= gle solution, and things that motivate people to deploy or not IPv6 may hav= e nothing to do with how IPv6 itself works. > I think in this discussion are again getting into the argument of "the=20 > best solution" instead of trying to collect the properties of the RA=20 > and DHCP. >=A0 > My position is that single best solution does not exist, because > everyone's problems are slightly different. So, rather than preaching=20 > for everyone to adopt the single solution which is the best in one=20 > scenario and suboptimal in the other, we should be engineering a way=20 > to be able to apply different solutions in different circumstances=20 > without the overhead of double work. >=A0 A single solution that solves most cases is better than two different, near= functionally equivalent solutions that solve the same cases. Multiple near= -equivalent solutions create more code, more bugs and then require conflict= resolution mechanisms, creating even more code and more bugs, with very li= ttle actual benefit. There are multiple ways of solving the neighbor discovery/router discovery/= host parameter configuration problem (read Radia Perlman's "Interconnection= s" book as a starting point, and then perhaps "Inside Appletalk", and also = look into Novell's IPX and Network Directory Services.). They all have diff= erent trade-offs, but fundamentally the trade-offs aren't significantly dif= ferent or compelling. Yet because there are multiple methods to solve these= problems, does that justify implementing all of them because they each hav= e some minor benefits over the others, that different people might prefer? Regards, Mark. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Fri Dec 6 18:13:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40F11AE051 for ; Fri, 6 Dec 2013 18:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWm-nZR-Y_X3 for ; Fri, 6 Dec 2013 18:13:07 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D50531AE002 for ; Fri, 6 Dec 2013 18:13:06 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB727qXC017077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Dec 2013 18:07:53 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB727qXC017077 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386382073; bh=4XWJV+uxfas33J68VHH7rN3I4w8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lv2qQ8VyD8K2/wF3XKsaZ2teFLXPjDW0CJRjasLtu2kaqXnivaKrb0codOLq+yPoi OnGqkZfKGa9oyEGkFWlejXDrwA/gpp/7euworWS0wb4Z/FQH8UD8FYP7b3sXzkComA byCiJbXF9jV6wYI6QAVMoQTqpiUv6rvOpM7B+Y18= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> Date: Fri, 6 Dec 2013 18:07:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 06 Dec 2013 18:07:53 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 02:13:11 -0000 On Dec 6, 2013, at 17:25 , Bernie Volz (volz) wrote: > Mark: >=20 > The difference between DHCPv6 and RA multicast is the direction. >=20 > DHCPv6 multicast is client to server (or relay). This has far fewer = problems in some networks because the first hop is typically on the = wired portion of the network (and the destination multicast address is = usually just joined by a few devices (relays and servers) - not all). You should study RA a little better. >=20 > RA multicast is router to client(s). This has problems in distributing = the traffic out to all of the clients over some networks. Only some RA is done this way. Clients starting up (and/or a client whose address is close to its = lifetime) send an RS message to a multicast group joined by only a few. = There are no "hops" because this is all link-local communication. Routers then respond either with a multicast or a unicast RA. As such, I think this provides at least the same reliability as DHCPv6 = per your comments above, while also providing the additional robustness you already attributed to all-hosts-multicast periodic RAs from the = routers. Owen >=20 > - Bernie >=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ = Smith > Sent: Friday, December 06, 2013 8:01 PM > To: Andrew Yourtchenko (ayourtch) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] New Version Notification for = draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >=20 >=20 > ----- Original Message ----- >> From: Andrew Yourtchenko >> To: Mark ZZZ Smith >> Cc: "v6ops@ietf.org" >> Sent: Saturday, 7 December 2013 3:34 AM >> Subject: Re: [v6ops] New Version Notification for=20 >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>=20 >> Hi Mark, >>=20 >> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: >>=20 >>> Hi, >>>=20 >>> Some criticisms/comments/questions on these pieces of text = relating=20 >>> to >> layer 2/wifi multicast reliablity: >>>=20 >>> "This is where the peer-to-peer, acknowledged nature of DHCPv6 may=20= >>> be >>> beneficial - on a crowded large-scale WiFi, without special tricks=20= >>> to ensure the reliable delivery of multicast packets, you simply = will=20 >>> not get the SLAAC working because the multicast RAs will get = crunched=20 >>> by the interference." >>> I'd think that if multicast is unreliable enough to cause RAs to=20= >>> fail to be delivered often enough, then anything which relies on=20 >>> multicast traffic is also likely to fail, which would include = neighbor discovery. >>> So regardless of if RAs were replaced with DHCPv6, the link is not=20= >>> going to provide reliable IPv6 operation, because IPv6 addresses=20 >>> cannot be reliably resolved to layer 2 addresses. >>>=20 >>> MLD would probably fail too, so any routed multicast applications,=20= >>> even low bandwidth ones, wouldn't work either, as would MLD = snooping=20 >>> based layer 2 forwarding optimisation. >>>=20 >>> DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that=20= >>> will >> probably be unreliable as well. >>>=20 >>> I don't think broadcasts on wifi are reliable, so IPv4 ARP would = be >> failing too. >>>=20 >>> So if RAs are failing because of not reliable enough multicast = then =20 >>> that is just one symptom of the link being overloaded, and there = will=20 >>> be others. >>=20 >> I think I capture several points here, tell me if I get them = correctly: >>=20 >> 1) There are other protocols that use multicast that will fail. >=20 > Yes.=20 >=20 >> 2) Fix your link. >>=20 >> for (1): RA is probably the only one that does not incorporate a=20 >> robust retransmit mechanism. >> =20 >=20 > In the case of multicast RAs there are two independent reliability = mechanisms used, one router side, one host side. >=20 > Firstly, the router lifetime in the RA is to be set to = AdvDefaultLifetime or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning = that for a host to lose knowledge of a router it has to miss 3 = unsolicited multicast RAs in a row. >=20 > Secondly, hosts retransmit their RSes multiple times (RFC4861, 6.3.7). >=20 > I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as = they only implement the second mechanism. For DHCPv6, neighbor discovery = and MLD to be as robust as RAs, the DHCPv6 server and the hosts would = have to also issue periodically unsolicited announcements of themselves = so that other hosts and routers don't have to solicit for them, unless = they have no existing knowledge of them. >=20 > (Should we add the ES-IS neighbor discovery model to IPv6 ND to make = it more robust? ES-IS has hosts periodically multicast their presence to = the link's routers, routers periodically multicast their presence to the = hosts, hosts default to sending to their routers for all destinations, = then routers sends a redirects to a host when the destination host is on = the same link.). >=20 >=20 >> for (2): It's great if you can, but I'd like to have protocol work in=20= >> all conditions. >=20 > That sound to me like an assertion that DHCPv6 is going to work in all = conditions. Given that DHCPv6 server discovery is less reliable than RAs = (because of the lack of unsolicited DHCPv6 server advertisements), how = is moving RA functions into DHCPv6 going to make DHCPv6 more reliable = than RAs? >=20 >> Especially that legacy IP does look more robust. >=20 >> =20 >=20 > So I'm curious why legacy IP is supposedly more robust? IPv4 uses = broadcasts for ARP and DHCP server discovery. On these links where IPv4 = "looks more robust" than IPv6, are broadcasts provided more reliable = delivery than multicasts, in particular as broadcasts must be flooded to = all hosts, where as multicasts can have their flooding scope limited = using MLD snooping? >=20 >=20 >>=20 >>> One idea I've had for this sort of scenario would be for the link = to =20 >>> operate as mostly an IPv6 over NBMA segment. The only multicasts on=20= >>> the link are RAs, providing the necessary NBMA operation = parameters.=20 >>> It of course would require changes to clients and routers, but then=20= >>> again, so would using DHCPv6 for what RAs are used for today. >>=20 >> You can do this with no changes today. >>=20 >> Block traffic between the hosts (similar to private vlan), advertise=20= >> prefixes as off-link, send all the traffic via the router on the = wired=20 >> side, block all the inbound ND from hosts except for the RS and NS=20 >> sent to solicited node address of the router + destined to the = router. >>=20 >> I tested this, it works like a charm - at least for the strawman=20 >> browsing scenario. >> =20 >=20 > Right, and doing that would solve the multicast capacity exhaustion = problems that would effect RA multicasts (and DHCPv6, ND and MLD = multicasts), because it is a more extreme case of constraining where = multicasts are sent than MLD snooping. >=20 > My Broadcast Multi-Access (BMA) link operating as NBMA suggestion = wouldn't require both having available and enabling any link-layer = special features to achieve the goal of significantly reducing multicast = traffic.=20 >=20 > (Thinking about it, the recent Efficient ND proposal is perhaps a = special case of operating a BMA link as an NBMA link for the Neighbor = Discovery protocol. I'm starting to wonder if it might be better to just = adopt this complete NBMA model over a BMA link and eliminate all = link-layer multicasts (ND, DHCPv6, MLD), except RAs to announce the BMA = link is operating in NBMA mode. The only multicasts would be unsolicited = RAs, which, for a single router, could be only once every 30 minutes (15 = minutes for two routers). I'd think that sort of interval would be = adequate to address the concerns of multicasts consuming mobile device = battery life.) >=20 >=20 >>>=20 >>> "Alternatively, in a very mobile environment and the RFC-compliant >>>=20 >>> router, multicast solicited RAs might make a significant portion = of >>> your traffic - which, due to a difference in modulation, etc. may=20= >>> eat >>> way more bandwidth than if they were sent unicast." >>>=20 >>> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a=20= >>> link can't handle 1 multicast every few seconds, it's also past the=20= >>> point >> of >>> it's capacity (and as above, other multicast/broadcast would also be=20= >>> contributing to exceeding link capacity.) >>=20 >> Modulation. Your multicast packets may take in the most extreme case=20= >> 54x time more airtime than a unicast. This means 54x more probability=20= >> it will be dropped. Also, forget the home wireless with one AP. Now=20= >> imagine >> 300-500 APs having to send these packets. You have 3 frequencies on=20= >> 2.4Ghz spectrum that you can use. So remembering that the whole=20 >> construct is 3D, you are *bound* to have some interference. >> =20 >=20 > Are all of those 300-500 APs in a single broadcast/multicast domain = i.e., one large link? That's convenient, but if multicasts/broadcasts = aren't reliable enough, that suggests the link capacity is exhausted. = Dividing the link up using routers to reduce multicast/broadcasts is and = has been the common solution since broadcast multiaccess links were = invented (which I think would be since around late 1970s when Ethernet = was invented). >=20 > Moving to an NBMA model by effectively modelling the BMA link as a = full mesh of virtual point-to-point links would probably be an = alternative method of overcoming multicast/broadcast capacity = limitations. >=20 >> So, it can be quite delicate in the most extreme cases. >>=20 >> And again, I want the protocol to be deployable in the most extreme=20= >> cases >> - especially when legacy IP survives them fine. >> =20 >=20 > How does it? Legacy IP uses broadcasts.=20 >=20 >> Yes, not everyone will have them. >>=20 >> But dismissing those cases just because they do not apply to one's=20 >> environment is incorrect. >>=20 >> And this is to me the whole point of the argument, which I would like=20= >> to get back to, instead of trying to argue about the details: >>=20 >> Yes, RA-only operation is *fantastic* for some circumstances. I love=20= >> it myself and do it whenever I can because this allows me to avoid=20 >> doing boring work. >>=20 >> But I may be forced to do DHCPv6. For any of the reasons already=20 >> present in the draft, pick one. And this means I am forced to do also=20= >> RA, which is a pain. >> =20 >=20 > So the objections I have are, >=20 > - I don't see how anything in DHCPv6 makes it dramatically more = reliable than RAs, given that it too uses multicasts for DHCPv6 server = discovery. Adding RA functions into DHCPv6 is described or asserted to = be the panacea to all issues that RAs could suffer from, yet analysis = shows it isn't. >=20 > - I think it would be better to incrementally tune and optimise the = existing designed, standardised, code developed, code debugged and = widely deployed mechanism (RAs) to overcome corner cases, and/or to = adopt past developed methods such as IPv6 over NBMA, than to spend the = next 5 to 10 years waiting for the design, standardisation, code = development, code debugging and widespread deployment of RA functions to = be incorporated into DHCPv6, and then also have to develop methods of = conflict resolution when RAs and DHCPv6 options disagree (because they = will, unless you don't plan to transition to DHCPv6 only until DHCPv6 RA = functions are ubiquitous. RAs and DHCPv6 RA functions will have to = co-exist on a link for many years if you can't demand or guarantee = DHCPv6 RA functionality from the host implementations.) >=20 > - Using DHCPv6 for RA functionality won't eliminate one of the = supposed causes of RA unreliability - multicast unreliability. All of = DHCPv6, neighbor discovery and MLD would have to be made more robust = against multicast unreliability to truly solve that problem. >=20 > - I'm for a single method that works adequately. DHCPv6 with RA = options would probably qualify if we didn't already have a existing = method. Existing methods that work are always better than non-existent = ones that need to be developed, tested and ubiquitously deployed before = they become significantly useful and can be assumed to be available. >=20 >=20 >> I think the large part of the tussle comes from the people wanting to=20= >> make the functionality of the RA/DHCPv6 more symmetric and being told=20= >> "no". >> =20 >=20 > The thing they need to demonstrate is that the costs of deploying a = new and second mechanism that is near functionally equivalent to the = first is worth the benefits. Given that the costs of developing and = deploying RAs has already been paid, I think the benefits of using = DHCPv6 for RA functions have to be very significant before the price = should be paid. The benefits of DHCPv6 for RA functions now needs to be = compelling. I don't think they are, otherwise I'd be quite happy to = advocate for DHCPv6 for RA functions. >=20 >=20 >> And if we then tell them "Either use RA or no IPv6 for you" they say >=20 >> "fine, I choose no IPv6". And keep stacking on these NATs to support=20= >> devices that "do not support IPv6" in that circumstances. >> =20 >=20 > I don't think RAs are the single reason some people are resisting = deploying IPv6 at all. I think some people are resisting deploying IPv6 = because it needs to do one or both of two things for them - solve a = foreseeable problem that will effect them, or provide a tangible = benefit. If it won't do either of those things, then they don't = currently see any value from the effort involved. What are foreseeable = problems or tangible benefits is completely up to the perspective of the = decision maker. Eventually they'll see value in it, and deploy it. In = some cases, some people who could deploy IPv6 may never see any value in = deploying it, so they never will. >=20 > There is no single answer to why people might resist deploying IPv6, = no single solution, and things that motivate people to deploy or not = IPv6 may have nothing to do with how IPv6 itself works. >=20 >=20 >=20 >> I think in this discussion are again getting into the argument of = "the=20 >> best solution" instead of trying to collect the properties of the RA=20= >> and DHCP. >> =20 >> My position is that single best solution does not exist, because >=20 >> everyone's problems are slightly different. So, rather than preaching=20= >> for everyone to adopt the single solution which is the best in one=20 >> scenario and suboptimal in the other, we should be engineering a way=20= >> to be able to apply different solutions in different circumstances=20 >> without the overhead of double work. >> =20 >=20 > A single solution that solves most cases is better than two different, = near functionally equivalent solutions that solve the same cases. = Multiple near-equivalent solutions create more code, more bugs and then = require conflict resolution mechanisms, creating even more code and more = bugs, with very little actual benefit. >=20 > There are multiple ways of solving the neighbor discovery/router = discovery/host parameter configuration problem (read Radia Perlman's = "Interconnections" book as a starting point, and then perhaps "Inside = Appletalk", and also look into Novell's IPX and Network Directory = Services.). They all have different trade-offs, but fundamentally the = trade-offs aren't significantly different or compelling. Yet because = there are multiple methods to solve these problems, does that justify = implementing all of them because they each have some minor benefits over = the others, that different people might prefer? >=20 > Regards, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Fri Dec 6 18:14:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA61AE0FB for ; Fri, 6 Dec 2013 18:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wn6PYxYB6KY for ; Fri, 6 Dec 2013 18:14:17 -0800 (PST) Received: from nm33-vm2.bullet.mail.bf1.yahoo.com (nm33-vm2.bullet.mail.bf1.yahoo.com [72.30.239.202]) by ietfa.amsl.com (Postfix) with SMTP id AEA271AE0F6 for ; Fri, 6 Dec 2013 18:14:16 -0800 (PST) Received: from [66.196.81.170] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 02:14:12 -0000 Received: from [98.139.212.198] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 02:14:12 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 02:14:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 723615.46650.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 23066 invoked by uid 60001); 7 Dec 2013 02:14:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1386382452; bh=In1mj0h3LnKg3WhzxUc02BeR6Uggar/UNf9jSimCdTg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1VHsB14qVBVtzPeVqpELeBHh6fLiqwCpoZjtVRKsoj+zZdDLBxuW5vJgRj2t0ykGDRVZdQg8bVj4+vdEhJQHIF8Q0s95nX+xNflmHSJwae34K4HMSW+YIc9CfRGqvFfH8iuSSiTPW2Bv0U4NQRxHpkWnstSLxn68dMmhwSkDrPc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iVTgRJOs8fyyY+FPq5H9onfqDmspLjAGIzTgrDqdBwd983sxEoRCe2LoEyStCpGPhKstE7kXJSca0gOJ9VxojefmBBohMalq+NSqow/GTMfKDcRM0L6EB21bpbiyuZ7u5lgn4Z1udOSjacBtEG19If4fUzfcxv5DMjCiRqAbo1M=; X-YMail-OSG: rCPJw5gVM1kAKYLyo4743pJcDNzx8Mg44rsVkqwmTBojA_u 4pxupDrkwLEPrG0N4SRwbncgUbHfFTavFqCYipAJjguLpE3Z61HUr9JrziYe WplsrFI5m1kVf7pyUpuXUhptUkfZgM.ttDndKbxkw607PkGagk1sUaDwlQm7 cFxAUhl_Is26C4NJBlGYglOTAYHHd0swRbaJuPW43tbB5U8APd_6fC2AYfW7 XI_JNr5AVEXWQqAKqA1KT5h19CYYk5ChCi1sTVeKgxxItrk_VuIVuMWZIVuh q7Rc4NPUNRs_dQ2ie4Pvbp8UqJ517tS5IZGFoWE86uS0rwNNLm0DPYThgFRY SLt1n8ZHHYxw9A0fkwrEWuwmLtKAvV4FW0SS4zD8Dv_qDj4pPy2YwR1dP3yv K4YsCmcRHoPG4UdkEqvtELFyRim4P8bCpbSXlGSut4FyJo4kbWC3zUx.1cq2 1Zadk2399HuM2RlbURtgO4YyjYZ_Bp0eECY.gA9uiZFu3.O2dfu7APYkCztU oZreFsHRkBP.OaEqpeYy6gaeWoDqAqPY18HSG0XYtrKdUZqEqLm4EWb_YbFJ T8wC58_BtMmNWHvKE.8I- Received: from [150.101.221.237] by web161902.mail.bf1.yahoo.com via HTTP; Fri, 06 Dec 2013 18:14:12 PST X-Rocket-MIMEInfo: 002.001, SGkgQmVybmllLAoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPgo.IFRvOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT47IEFuZHJldyBZb3VydGNoZW5rbyAoYXlvdXJ0Y2gpIDxheW91cnRjaEBjaXNjby5jb20.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IFNhdHVyZGF5LCA3IERlY2VtYmVyIDIwMTMgMTI6MjUgUE0KPiBTdWJqZWN0OiBSRTogW3Y2b3ABMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> Message-ID: <1386382452.71895.YahooMailNeo@web161902.mail.bf1.yahoo.com> Date: Fri, 6 Dec 2013 18:14:12 -0800 (PST) From: Mark ZZZ Smith To: "Bernie Volz \(volz\)" , "Andrew Yourtchenko \(ayourtch\)" In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 02:14:19 -0000 Hi Bernie,=0A=0A=0A----- Original Message -----=0A> From: Bernie Volz (volz= ) =0A> To: Mark ZZZ Smith ; Andr= ew Yourtchenko (ayourtch) =0A> Cc: "v6ops@ietf.org" =0A> Sent: Saturday, 7 December 2013 12:25 PM=0A> Subject: RE:= [v6ops] New Version Notification for=09draft-yourtchenko-ra-dhcpv6-compari= son-00.txt (fwd)=0A> =0A> Mark:=0A> =0A> The difference between DHCPv6 and = RA multicast is the direction.=0A>=A0=0A=0AThat's a good point.=0A=0A> DHCP= v6 multicast is client to server (or relay). This has far fewer problems in= =0A> some networks because the first hop is typically on the wired portion= of the =0A> network (and the destination multicast address is usually just= joined by a few =0A> devices (relays and servers) - not all).=0A> =0A> RA = multicast is router to client(s). This has problems in distributing the =0A= > traffic out to all of the clients over some networks.=0A>=A0=0A=0AI'd thi= nk in that case multicast RS / unicast RA response mechanism could be used.= Perhaps the thing to tweak in RAs to better suit this scenario would be to= change the default of responding to multicast RSes with a multicast RA to = responding with a unicast RA, as allowed in 6.2.6 of RFC4861.=0A=0A=0AThank= s,=0AMark.=0A=0A=0A=0A> - Bernie=0A> =0A> =0A> -----Original Message-----= =0A> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smit= h=0A> Sent: Friday, December 06, 2013 8:01 PM=0A> To: Andrew Yourtchenko (a= yourtch)=0A> Cc: v6ops@ietf.org=0A> Subject: Re: [v6ops] New Version Notifi= cation for =0A> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)=0A> =0A= > =0A> ----- Original Message -----=0A>> From: Andrew Yourtchenko =0A>> To: Mark ZZZ Smith =0A>> Cc:= "v6ops@ietf.org" =0A>> Sent: Saturday, 7 December 2013 3:= 34 AM=0A>> Subject: Re: [v6ops] New Version Notification for =0A>> draft-= yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)=0A>> =0A>> Hi Mark,=0A>> =0A= >> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote:=0A>> =0A>>> =A0=A0Hi,=0A>>> = =0A>>> =A0=A0Some criticisms/comments/questions on these pieces of text rel= ating =0A>>> to=0A>> layer 2/wifi multicast reliablity:=0A>>> =0A>>> =A0= =A0"This is where the peer-to-peer, acknowledged nature of DHCPv6 =0A> may = =0A>>> be=0A>>> =A0=A0beneficial - on a crowded large-scale WiFi, without s= pecial tricks =0A>>> to=A0 ensure the reliable delivery of multicast packet= s, you simply will =0A>>> not=A0 get the SLAAC working because the multicas= t RAs will get crunched =0A>>> by the=A0 interference."=0A>>> =A0=A0I'd thi= nk that if multicast is unreliable enough to cause RAs to =0A>>> fail=A0 to= be delivered often enough, then anything which relies on =0A>>> multicast= =A0 traffic is also likely to fail, which would include neighbor =0A> disco= very.=0A>>> So regardless of if RAs were replaced with DHCPv6, the link is= not =0A>>> going=A0 to provide reliable IPv6 operation, because IPv6=A0add= resses =0A>>> cannot be=A0 reliably resolved to layer 2 addresses.=0A>>> = =0A>>> =A0=A0MLD would probably fail too, so any routed multicast applicati= ons, =0A>>> even=A0 low bandwidth ones, wouldn't work either, as would MLD = =0A> snooping =0A>>> based=A0 layer 2 forwarding optimisation.=0A>>> =0A>>>= =A0=A0DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that =0A= >>> will=0A>> probably be unreliable as well.=0A>>> =0A>>> =A0=A0I don't t= hink broadcasts on wifi are reliable, so IPv4 ARP would =0A> be=0A>> faili= ng too.=0A>>> =0A>>> =A0=A0So if RAs are failing because of not reliable en= ough multicast then=A0 =0A>>> that is just one symptom of the link being ov= erloaded, and there will =0A>>> be=A0 others.=0A>> =0A>> I think I capture= several points here, tell me if I get them correctly:=0A>> =0A>> 1) There= are other protocols that use multicast that will fail.=0A> =0A> Yes.=A0=0A= > =0A>> 2) Fix your link.=0A>> =0A>> for (1): RA is probably the only one= that does not incorporate a =0A>> robust retransmit mechanism.=0A>> =A0= =0A> =0A> In the case of multicast RAs there are two independent reliabilit= y mechanisms =0A> used, one router side, one host side.=0A> =0A> Firstly, t= he router lifetime in the RA is to be set to AdvDefaultLifetime or 3 * =0A>= MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to lose knowle= dge of =0A> a router it has to miss 3 unsolicited multicast RAs in a row.= =0A> =0A> Secondly, hosts retransmit their RSes multiple times (RFC4861, 6.= 3.7).=0A> =0A> I'd argue that DHCPv6, neighbor discovery and MLD are less r= obust, as they =0A> only implement the second mechanism. For DHCPv6, neighb= or discovery and MLD to =0A> be as robust as RAs, the DHCPv6 server and the= hosts would have to also issue =0A> periodically unsolicited announcements= of themselves so that other hosts and =0A> routers don't have to solicit f= or them, unless they have no existing =0A> knowledge of them.=0A> =0A> (Sho= uld we add the ES-IS neighbor discovery model to IPv6 ND to make it more = =0A> robust? ES-IS has hosts periodically multicast their presence to the l= ink's =0A> routers, routers periodically multicast their presence to the ho= sts, hosts =0A> default to sending to their routers for all destinations, t= hen routers sends a =0A> redirects to a host when the destination host is o= n the same link.).=0A> =0A> =0A>> for (2): It's great if you can, but I'd = like to have protocol work =0A> in =0A>> all conditions.=0A> =0A> That sou= nd to me like an assertion that DHCPv6 is going to work in all =0A> conditi= ons. Given that DHCPv6 server discovery is less reliable than RAs =0A> (bec= ause of the lack of unsolicited DHCPv6 server advertisements), how is movin= g =0A> RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs= ?=0A> =0A>> Especially that legacy IP does look more robust.=0A> =0A>> =A0= =0A> =0A> So I'm curious why legacy IP is supposedly more robust? IPv4 uses= broadcasts =0A> for ARP and DHCP server discovery. On these links where IP= v4 "looks more =0A> robust" than IPv6, are broadcasts provided more reliabl= e delivery than =0A> multicasts, in particular as broadcasts must be floode= d to all hosts, where as =0A> multicasts can have their flooding scope limi= ted using MLD snooping?=0A> =0A> =0A>> =0A>>> =A0=A0One idea I've had for t= his sort of scenario would be for the link =0A> to=A0 =0A>>> operate as mos= tly an IPv6 over NBMA segment. The only multicasts on =0A>>> the=A0 link ar= e RAs, providing the necessary NBMA operation parameters. =0A>>> It of=A0 c= ourse would require changes to clients and routers, but then =0A>>> again, = so=A0 would using DHCPv6 for what RAs are used for today.=0A>> =0A>> You c= an do this with no changes today.=0A>> =0A>> Block traffic between the hos= ts (similar to private vlan), advertise =0A>> prefixes as off-link, send a= ll the traffic via the router on the wired =0A>> side, block all the inbou= nd ND from hosts except for the RS and NS =0A>> sent to solicited node add= ress of the router + destined to the router.=0A>> =0A>> I tested this, it = works like a charm - at least for the strawman =0A>> browsing scenario.=0A= >> =A0=0A> =0A> Right, and doing that would solve the multicast capacity ex= haustion problems =0A> that would effect RA multicasts (and DHCPv6, ND and = MLD multicasts), because it =0A> is a more extreme case of constraining whe= re multicasts are sent than MLD =0A> snooping.=0A> =0A> My Broadcast Multi-= Access (BMA) link operating as NBMA suggestion wouldn't =0A> require both h= aving available and enabling any link-layer special features to =0A> achiev= e the goal of significantly reducing multicast traffic.=A0=0A> =0A> (Thinki= ng about it, the recent Efficient ND proposal is perhaps a special case =0A= > of operating a BMA link as an NBMA link for the Neighbor Discovery protoc= ol. =0A> I'm starting to wonder if it might be better to just adopt this co= mplete =0A> NBMA model over a BMA link and eliminate all link-layer multica= sts (ND, DHCPv6, =0A> MLD), except RAs to announce the BMA link is operatin= g in NBMA mode. The only =0A> multicasts would be unsolicited RAs, which, f= or a single router, could be only =0A> once every 30 minutes (15 minutes fo= r two routers). I'd think that sort of =0A> interval would be adequate to a= ddress the concerns of multicasts consuming =0A> mobile device battery life= .)=0A> =0A> =0A>>> =0A>>> =A0=A0"Alternatively, in a very mobile environmen= t and the =0A> RFC-compliant=0A>>> =0A>>> =A0=A0router, multicast solicited= RAs might make a significant portion of=0A>>> =A0=A0your traffic - which, = due to a difference in modulation, etc.=A0 may =0A>>> eat=0A>>> =A0=A0way m= ore bandwidth than if they were sent unicast."=0A>>> =0A>>> =A0=A0The MIN_D= ELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a =0A>>> link=A0 can= 't handle 1 multicast every few seconds, it's also past =0A> the =0A>>> poi= nt=0A>> of=0A>>> it's capacity (and as above, other multicast/broadcast w= ould also =0A> be =0A>>> contributing to exceeding link capacity.)=0A>> = =0A>> Modulation. Your multicast packets may take in the most extreme case= =0A>> 54x time more airtime than a unicast. This means 54x more probabili= ty =0A>> it will be dropped. Also, forget the home wireless with one AP. N= ow =0A>> imagine=0A>> 300-500 APs having to send these packets. You have = 3 frequencies on =0A>> 2.4Ghz spectrum that you can use. So remembering th= at the whole =0A>> construct is 3D, you are *bound* to have some interfere= nce.=0A>> =A0=0A> =0A> Are all of those 300-500 APs in a single broadcast/m= ulticast domain i.e., one =0A> large link? That's convenient, but if multic= asts/broadcasts aren't =0A> reliable enough, that suggests the link capacit= y is exhausted. Dividing the link =0A> up using routers to reduce multicast= /broadcasts is and has been the common =0A> solution since broadcast multia= ccess links were invented (which I think would be =0A> since around late 19= 70s when Ethernet was invented).=0A> =0A> Moving to an NBMA model by effect= ively modelling the BMA link as a full mesh of =0A> virtual point-to-point = links would probably be an alternative method of =0A> overcoming multicast/= broadcast capacity limitations.=0A> =0A>> So, it can be quite delicate in = the most extreme cases.=0A>> =0A>> And again, I want the protocol to be de= ployable in the most extreme =0A>> cases=0A>> - especially when legacy IP= survives them fine.=0A>> =A0=0A> =0A> How does it? Legacy IP uses broadcas= ts.=A0=0A> =0A>> Yes, not everyone will have them.=0A>> =0A>> But dismiss= ing those cases just because they do not apply to one's =0A>> environment = is incorrect.=0A>> =0A>> And this is to me the whole point of the argument= , which I would like =0A>> to get back to, instead of trying to argue abou= t the details:=0A>> =0A>> Yes, RA-only operation is *fantastic* for some c= ircumstances. I love =0A>> it myself and do it whenever I can because this= allows me to avoid =0A>> doing boring work.=0A>> =0A>> But I may be forc= ed to do DHCPv6. For any of the reasons already =0A>> present in the draft= , pick one. And this means I am forced to do also =0A>> RA, which is a pai= n.=0A>> =A0=0A> =0A> So the objections I have are,=0A> =0A> - I don't see h= ow anything in DHCPv6 makes it dramatically more reliable =0A> than RAs, gi= ven that it too uses multicasts for DHCPv6 server discovery. Adding =0A> RA= functions into DHCPv6 is described or asserted to be the panacea to all = =0A> issues that RAs could suffer from, yet analysis shows it isn't.=0A> = =0A> - I think it would be better to incrementally tune and optimise the ex= isting =0A> designed, standardised, code developed, code debugged and widel= y deployed =0A> mechanism (RAs) to overcome corner cases, and/or to adopt p= ast developed methods =0A> such as IPv6 over NBMA, than to spend the next 5= to 10 years waiting for the =0A> design, standardisation, code development= , code debugging and widespread =0A> deployment of RA functions to be incor= porated into DHCPv6, and then also have to =0A> develop methods of conflict= resolution when RAs and DHCPv6 options disagree =0A> (because they will, u= nless you don't plan to transition to DHCPv6 only until =0A> DHCPv6 RA func= tions are ubiquitous. RAs and DHCPv6 RA functions will have to =0A> co-exis= t on a link for many years if you can't demand or guarantee DHCPv6 RA =0A> = functionality from the host implementations.)=0A> =0A> - Using DHCPv6 for R= A functionality won't eliminate one of the supposed =0A> causes of RA unrel= iability - multicast unreliability. All of DHCPv6, neighbor =0A> discovery = and MLD would have to be made more robust against multicast =0A> unreliabil= ity to truly solve that problem.=0A> =0A> - I'm for a single method that wo= rks adequately. DHCPv6 with RA options =0A> would probably qualify if we di= dn't already have a existing method. Existing =0A> methods that work are al= ways better than non-existent ones that need to be =0A> developed, tested a= nd ubiquitously deployed before they become significantly =0A> useful and c= an be assumed to be available.=0A> =0A> =0A>> I think the large part of th= e tussle comes from the people wanting to =0A>> make the functionality of = the RA/DHCPv6 more symmetric and being told =0A>> "no".=0A>> =A0=0A> =0A> = The thing they need to demonstrate is that the costs of deploying a new and= =0A> second mechanism that is near functionally equivalent to the first is= worth the =0A> benefits. Given that the costs of developing and deploying = RAs has already been =0A> paid, I think the benefits of using DHCPv6 for RA= functions have to be very =0A> significant=A0before the price should be pa= id. The benefits of DHCPv6 for RA =0A> functions now needs to be compelling= . I don't think they are, otherwise =0A> I'd be quite happy to advocate for= DHCPv6 for RA functions.=0A> =0A> =0A>> And if we then tell them "Either = use RA or no IPv6 for you" they =0A> say=0A> =0A>> "fine, I choose no IPv6= ". And keep stacking on these NATs to =0A> support =0A>> devices that "do = not support IPv6" in that circumstances.=0A>> =A0=0A> =0A> I don't think RA= s are the single reason some people are resisting deploying =0A> IPv6 at al= l. I think some people are resisting deploying IPv6 because it needs =0A> t= o do one or both of two things for them - solve a foreseeable problem that = will =0A> effect them, or provide a tangible benefit. If it won't do either= of those =0A> things, then they don't currently see any value from the eff= ort involved. =0A> What are foreseeable problems or tangible benefits is co= mpletely up to the =0A> perspective of the decision maker. Eventually they'= ll see value in it, and =0A> deploy it. In some cases, some people who coul= d deploy IPv6 may never see any =0A> value in deploying it, so they never w= ill.=0A> =0A> There is no single answer to why people might resist deployin= g IPv6, no single =0A> solution, and things that motivate people to deploy = or not IPv6 may have nothing =0A> to do with how IPv6 itself works.=0A> =0A= > =0A> =0A>> I think in this discussion are again getting into the argumen= t of "the =0A> =0A>> best solution" instead of trying to collect the prope= rties of the RA =0A>> and DHCP.=0A>> =A0=0A>> My position is that single = best solution does not exist, because=0A> =0A>> everyone's problems are sl= ightly different. So, rather than preaching =0A>> for everyone to adopt th= e single solution which is the best in one =0A>> scenario and suboptimal i= n the other, we should be engineering a way =0A>> to be able to apply diff= erent solutions in different circumstances =0A>> without the overhead of d= ouble work.=0A>> =A0=0A> =0A> A single solution that solves most cases is b= etter than two different, near =0A> functionally equivalent solutions that = solve the same cases. Multiple =0A> near-equivalent solutions create more c= ode, more bugs and then require conflict =0A> resolution mechanisms, creati= ng even more code and more bugs, with very little =0A> actual benefit.=0A> = =0A> There are multiple ways of solving the neighbor discovery/router disco= very/host =0A> parameter configuration problem (read Radia Perlman's =0A> "= Interconnections" book as a starting point, and then perhaps =0A> "Inside A= ppletalk", and also look into Novell's IPX and Network =0A> Directory Servi= ces.). They all have different trade-offs, but fundamentally the =0A> trade= -offs aren't significantly different or compelling. Yet because there =0A> = are multiple methods to solve these problems, does that justify implementin= g all =0A> of them because they each have some minor benefits over the othe= rs, that =0A> different people might prefer?=0A> =0A> Regards,=0A> Mark.=0A= > _______________________________________________=0A> v6ops mailing list=0A= > v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From volz@cisco.com Fri Dec 6 18:25:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7820B1AE149 for ; Fri, 6 Dec 2013 18:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-_x-vOy3SXV for ; Fri, 6 Dec 2013 18:25:36 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id BF24B1AE0F6 for ; Fri, 6 Dec 2013 18:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16991; q=dns/txt; s=iport; t=1386383132; x=1387592732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3WWU+DXGvCVgMrox8xz34Vf39GqCYVn3h2+t5FyK+6o=; b=PCOLmav4wPVZLj/gd5WpfAK0SR+dZefxixgQAC2a8ibcwpA3nWEPpAlQ BPhEU2HQt5dl+MLyYWbLZB8vpgd6SiZg3noWYD4VPSLbOUtBENBctJCYg ZUiRBLL486AvwCiK5lQBBJtCSyxIabd1iWGNjbvMeIENNxFjOEALcoxI5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogSAAKGolKtJXHA/2dsb2JhbABZgXECAYETOFO5EoEfFnSCJQEBAQMBAQEBNzQJAgUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQgRAodVAwkGDbFbjxkTBIx9gSsQJzEHBoMagRMDli+OP4U5gWuBPoFoQg X-IronPort-AV: E=Sophos;i="4.93,843,1378857600"; d="scan'208";a="4989115" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 07 Dec 2013 02:25:30 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB72PUcD010471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Dec 2013 02:25:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 20:25:30 -0600 From: "Bernie Volz (volz)" To: Owen DeLong Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO8ufo8sOhdw9Xj0eSkw7nY3E0jZpH73mQgABxZYD//5/CwA== Date: Sat, 7 Dec 2013 02:25:29 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> In-Reply-To: <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 02:25:39 -0000 Yes, I am aware of that - unicast RA from the router to the client is avail= able. Just isn't clear now often it is used. But, this doesn't address the periodic RAs normally sent by routers as thos= e are multicast. - Bernie -----Original Message----- From: Owen DeLong [mailto:owen@delong.com]=20 Sent: Friday, December 06, 2013 9:07 PM To: Bernie Volz (volz) Cc: Mark ZZZ Smith; Andrew Yourtchenko (ayourtch); v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcp= v6-comparison-00.txt (fwd) On Dec 6, 2013, at 17:25 , Bernie Volz (volz) wrote: > Mark: >=20 > The difference between DHCPv6 and RA multicast is the direction. >=20 > DHCPv6 multicast is client to server (or relay). This has far fewer probl= ems in some networks because the first hop is typically on the wired portio= n of the network (and the destination multicast address is usually just joi= ned by a few devices (relays and servers) - not all). You should study RA a little better. >=20 > RA multicast is router to client(s). This has problems in distributing th= e traffic out to all of the clients over some networks. Only some RA is done this way. Clients starting up (and/or a client whose address is close to its lifetime= ) send an RS message to a multicast group joined by only a few. There are n= o "hops" because this is all link-local communication. Routers then respond either with a multicast or a unicast RA. As such, I think this provides at least the same reliability as DHCPv6 per = your comments above, while also providing the additional robustness you alr= eady attributed to all-hosts-multicast periodic RAs from the routers. Owen >=20 > - Bernie >=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ=20 > Smith > Sent: Friday, December 06, 2013 8:01 PM > To: Andrew Yourtchenko (ayourtch) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] New Version Notification for=20 > draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >=20 >=20 > ----- Original Message ----- >> From: Andrew Yourtchenko >> To: Mark ZZZ Smith >> Cc: "v6ops@ietf.org" >> Sent: Saturday, 7 December 2013 3:34 AM >> Subject: Re: [v6ops] New Version Notification for=20 >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>=20 >> Hi Mark, >>=20 >> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: >>=20 >>> Hi, >>>=20 >>> Some criticisms/comments/questions on these pieces of text=20 >>> relating to >> layer 2/wifi multicast reliablity: >>>=20 >>> "This is where the peer-to-peer, acknowledged nature of DHCPv6 may=20 >>> be >>> beneficial - on a crowded large-scale WiFi, without special tricks=20 >>> to ensure the reliable delivery of multicast packets, you simply=20 >>> will not get the SLAAC working because the multicast RAs will get=20 >>> crunched by the interference." >>> I'd think that if multicast is unreliable enough to cause RAs to=20 >>> fail to be delivered often enough, then anything which relies on=20 >>> multicast traffic is also likely to fail, which would include neighbor= discovery. >>> So regardless of if RAs were replaced with DHCPv6, the link is not=20 >>> going to provide reliable IPv6 operation, because IPv6 addresses=20 >>> cannot be reliably resolved to layer 2 addresses. >>>=20 >>> MLD would probably fail too, so any routed multicast applications,=20 >>> even low bandwidth ones, wouldn't work either, as would MLD=20 >>> snooping based layer 2 forwarding optimisation. >>>=20 >>> DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that=20 >>> will >> probably be unreliable as well. >>>=20 >>> I don't think broadcasts on wifi are reliable, so IPv4 ARP would=20 >>> be >> failing too. >>>=20 >>> So if RAs are failing because of not reliable enough multicast=20 >>> then that is just one symptom of the link being overloaded, and=20 >>> there will be others. >>=20 >> I think I capture several points here, tell me if I get them correctly: >>=20 >> 1) There are other protocols that use multicast that will fail. >=20 > Yes.=20 >=20 >> 2) Fix your link. >>=20 >> for (1): RA is probably the only one that does not incorporate a=20 >> robust retransmit mechanism. >> =20 >=20 > In the case of multicast RAs there are two independent reliability mechan= isms used, one router side, one host side. >=20 > Firstly, the router lifetime in the RA is to be set to AdvDefaultLifetime= or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to lose= knowledge of a router it has to miss 3 unsolicited multicast RAs in a row. >=20 > Secondly, hosts retransmit their RSes multiple times (RFC4861, 6.3.7). >=20 > I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as the= y only implement the second mechanism. For DHCPv6, neighbor discovery and M= LD to be as robust as RAs, the DHCPv6 server and the hosts would have to al= so issue periodically unsolicited announcements of themselves so that other= hosts and routers don't have to solicit for them, unless they have no exis= ting knowledge of them. >=20 > (Should we add the ES-IS neighbor discovery model to IPv6 ND to make it m= ore robust? ES-IS has hosts periodically multicast their presence to the li= nk's routers, routers periodically multicast their presence to the hosts, h= osts default to sending to their routers for all destinations, then routers= sends a redirects to a host when the destination host is on the same link.= ). >=20 >=20 >> for (2): It's great if you can, but I'd like to have protocol work in=20 >> all conditions. >=20 > That sound to me like an assertion that DHCPv6 is going to work in all co= nditions. Given that DHCPv6 server discovery is less reliable than RAs (bec= ause of the lack of unsolicited DHCPv6 server advertisements), how is movin= g RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs? >=20 >> Especially that legacy IP does look more robust. >=20 >> =20 >=20 > So I'm curious why legacy IP is supposedly more robust? IPv4 uses broadca= sts for ARP and DHCP server discovery. On these links where IPv4 "looks mor= e robust" than IPv6, are broadcasts provided more reliable delivery than mu= lticasts, in particular as broadcasts must be flooded to all hosts, where a= s multicasts can have their flooding scope limited using MLD snooping? >=20 >=20 >>=20 >>> One idea I've had for this sort of scenario would be for the link=20 >>> to operate as mostly an IPv6 over NBMA segment. The only multicasts=20 >>> on the link are RAs, providing the necessary NBMA operation parameters= . >>> It of course would require changes to clients and routers, but then=20 >>> again, so would using DHCPv6 for what RAs are used for today. >>=20 >> You can do this with no changes today. >>=20 >> Block traffic between the hosts (similar to private vlan), advertise=20 >> prefixes as off-link, send all the traffic via the router on the=20 >> wired side, block all the inbound ND from hosts except for the RS and=20 >> NS sent to solicited node address of the router + destined to the router= . >>=20 >> I tested this, it works like a charm - at least for the strawman=20 >> browsing scenario. >> =20 >=20 > Right, and doing that would solve the multicast capacity exhaustion probl= ems that would effect RA multicasts (and DHCPv6, ND and MLD multicasts), be= cause it is a more extreme case of constraining where multicasts are sent t= han MLD snooping. >=20 > My Broadcast Multi-Access (BMA) link operating as NBMA suggestion wouldn'= t require both having available and enabling any link-layer special feature= s to achieve the goal of significantly reducing multicast traffic.=20 >=20 > (Thinking about it, the recent Efficient ND proposal is perhaps a=20 > special case of operating a BMA link as an NBMA link for the Neighbor=20 > Discovery protocol. I'm starting to wonder if it might be better to=20 > just adopt this complete NBMA model over a BMA link and eliminate all=20 > link-layer multicasts (ND, DHCPv6, MLD), except RAs to announce the=20 > BMA link is operating in NBMA mode. The only multicasts would be=20 > unsolicited RAs, which, for a single router, could be only once every=20 > 30 minutes (15 minutes for two routers). I'd think that sort of=20 > interval would be adequate to address the concerns of multicasts=20 > consuming mobile device battery life.) >=20 >=20 >>>=20 >>> "Alternatively, in a very mobile environment and the RFC-compliant >>>=20 >>> router, multicast solicited RAs might make a significant portion of >>> your traffic - which, due to a difference in modulation, etc. may=20 >>> eat >>> way more bandwidth than if they were sent unicast." >>>=20 >>> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a=20 >>> link can't handle 1 multicast every few seconds, it's also past the=20 >>> point >> of >>> it's capacity (and as above, other multicast/broadcast would also be=20 >>> contributing to exceeding link capacity.) >>=20 >> Modulation. Your multicast packets may take in the most extreme case=20 >> 54x time more airtime than a unicast. This means 54x more probability=20 >> it will be dropped. Also, forget the home wireless with one AP. Now=20 >> imagine >> 300-500 APs having to send these packets. You have 3 frequencies on=20 >> 2.4Ghz spectrum that you can use. So remembering that the whole=20 >> construct is 3D, you are *bound* to have some interference. >> =20 >=20 > Are all of those 300-500 APs in a single broadcast/multicast domain i.e.,= one large link? That's convenient, but if multicasts/broadcasts aren't rel= iable enough, that suggests the link capacity is exhausted. Dividing the li= nk up using routers to reduce multicast/broadcasts is and has been the comm= on solution since broadcast multiaccess links were invented (which I think = would be since around late 1970s when Ethernet was invented). >=20 > Moving to an NBMA model by effectively modelling the BMA link as a full m= esh of virtual point-to-point links would probably be an alternative method= of overcoming multicast/broadcast capacity limitations. >=20 >> So, it can be quite delicate in the most extreme cases. >>=20 >> And again, I want the protocol to be deployable in the most extreme=20 >> cases >> - especially when legacy IP survives them fine. >> =20 >=20 > How does it? Legacy IP uses broadcasts.=20 >=20 >> Yes, not everyone will have them. >>=20 >> But dismissing those cases just because they do not apply to one's=20 >> environment is incorrect. >>=20 >> And this is to me the whole point of the argument, which I would like=20 >> to get back to, instead of trying to argue about the details: >>=20 >> Yes, RA-only operation is *fantastic* for some circumstances. I love=20 >> it myself and do it whenever I can because this allows me to avoid=20 >> doing boring work. >>=20 >> But I may be forced to do DHCPv6. For any of the reasons already=20 >> present in the draft, pick one. And this means I am forced to do also=20 >> RA, which is a pain. >> =20 >=20 > So the objections I have are, >=20 > - I don't see how anything in DHCPv6 makes it dramatically more reliable = than RAs, given that it too uses multicasts for DHCPv6 server discovery. Ad= ding RA functions into DHCPv6 is described or asserted to be the panacea to= all issues that RAs could suffer from, yet analysis shows it isn't. >=20 > - I think it would be better to incrementally tune and optimise the=20 > existing designed, standardised, code developed, code debugged and=20 > widely deployed mechanism (RAs) to overcome corner cases, and/or to=20 > adopt past developed methods such as IPv6 over NBMA, than to spend the=20 > next 5 to 10 years waiting for the design, standardisation, code=20 > development, code debugging and widespread deployment of RA functions=20 > to be incorporated into DHCPv6, and then also have to develop methods=20 > of conflict resolution when RAs and DHCPv6 options disagree (because=20 > they will, unless you don't plan to transition to DHCPv6 only until=20 > DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will=20 > have to co-exist on a link for many years if you can't demand or=20 > guarantee DHCPv6 RA functionality from the host implementations.) >=20 > - Using DHCPv6 for RA functionality won't eliminate one of the supposed c= auses of RA unreliability - multicast unreliability. All of DHCPv6, neighbo= r discovery and MLD would have to be made more robust against multicast unr= eliability to truly solve that problem. >=20 > - I'm for a single method that works adequately. DHCPv6 with RA options w= ould probably qualify if we didn't already have a existing method. Existing= methods that work are always better than non-existent ones that need to be= developed, tested and ubiquitously deployed before they become significant= ly useful and can be assumed to be available. >=20 >=20 >> I think the large part of the tussle comes from the people wanting to=20 >> make the functionality of the RA/DHCPv6 more symmetric and being told=20 >> "no". >> =20 >=20 > The thing they need to demonstrate is that the costs of deploying a new a= nd second mechanism that is near functionally equivalent to the first is wo= rth the benefits. Given that the costs of developing and deploying RAs has = already been paid, I think the benefits of using DHCPv6 for RA functions ha= ve to be very significant before the price should be paid. The benefits of = DHCPv6 for RA functions now needs to be compelling. I don't think they are,= otherwise I'd be quite happy to advocate for DHCPv6 for RA functions. >=20 >=20 >> And if we then tell them "Either use RA or no IPv6 for you" they say >=20 >> "fine, I choose no IPv6". And keep stacking on these NATs to support=20 >> devices that "do not support IPv6" in that circumstances. >> =20 >=20 > I don't think RAs are the single reason some people are resisting deployi= ng IPv6 at all. I think some people are resisting deploying IPv6 because it= needs to do one or both of two things for them - solve a foreseeable probl= em that will effect them, or provide a tangible benefit. If it won't do eit= her of those things, then they don't currently see any value from the effor= t involved. What are foreseeable problems or tangible benefits is completel= y up to the perspective of the decision maker. Eventually they'll see value= in it, and deploy it. In some cases, some people who could deploy IPv6 may= never see any value in deploying it, so they never will. >=20 > There is no single answer to why people might resist deploying IPv6, no s= ingle solution, and things that motivate people to deploy or not IPv6 may h= ave nothing to do with how IPv6 itself works. >=20 >=20 >=20 >> I think in this discussion are again getting into the argument of=20 >> "the best solution" instead of trying to collect the properties of=20 >> the RA and DHCP. >> =20 >> My position is that single best solution does not exist, because >=20 >> everyone's problems are slightly different. So, rather than preaching=20 >> for everyone to adopt the single solution which is the best in one=20 >> scenario and suboptimal in the other, we should be engineering a way=20 >> to be able to apply different solutions in different circumstances=20 >> without the overhead of double work. >> =20 >=20 > A single solution that solves most cases is better than two different, ne= ar functionally equivalent solutions that solve the same cases. Multiple ne= ar-equivalent solutions create more code, more bugs and then require confli= ct resolution mechanisms, creating even more code and more bugs, with very = little actual benefit. >=20 > There are multiple ways of solving the neighbor discovery/router discover= y/host parameter configuration problem (read Radia Perlman's "Interconnecti= ons" book as a starting point, and then perhaps "Inside Appletalk", and als= o look into Novell's IPX and Network Directory Services.). They all have di= fferent trade-offs, but fundamentally the trade-offs aren't significantly d= ifferent or compelling. Yet because there are multiple methods to solve the= se problems, does that justify implementing all of them because they each h= ave some minor benefits over the others, that different people might prefer= ? >=20 > Regards, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From owen@delong.com Fri Dec 6 18:42:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E345C1AE137 for ; Fri, 6 Dec 2013 18:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNkDMdC1C3yT for ; Fri, 6 Dec 2013 18:42:53 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 15B6F1AE12A for ; Fri, 6 Dec 2013 18:42:53 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB72dhVV017706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Dec 2013 18:39:43 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB72dhVV017706 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386383983; bh=OBCQAuHYNKFq9RUMqyW7xHLukPQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PyxYyI3o/z4qh51Bt/IGpLK54mWKOixgdEPIKgM4qQB/5GZs5/fL31f/6snarghHi mV/0dO/ksqpDTazsEIaMHiUPkpYh/ojZAgUsGmtn/CtsEPKm7Og5MhiNmIzSTm++ct 7yuFCaQLGJveBkDX6U/NOg+qRlerHPZPMdekjaBc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> Date: Fri, 6 Dec 2013 18:39:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 06 Dec 2013 18:39:43 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 02:42:56 -0000 I see unicast RAs from time to time on my network. Haven't delved too = deeply into whether they come from the Juniper, Mikrotik, Linux, or all = three. Sorry, I stopped using $C here years ago because the power and cooling = were getting out of hand compared to what I could do with much cheaper = $M and $J boxes. (This is my home network, 2620:0:930::/48. I'm not speaking of or for = $DAYJOB at the moment). Is a link-local multicast on WiFi implemented as multiple unicasts for = some reason? If not, then I can't imagine it would be any worse than = ARP. Owen On Dec 6, 2013, at 18:25 , Bernie Volz (volz) wrote: > Yes, I am aware of that - unicast RA from the router to the client is = available. Just isn't clear now often it is used. >=20 > But, this doesn't address the periodic RAs normally sent by routers as = those are multicast. >=20 > - Bernie >=20 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com]=20 > Sent: Friday, December 06, 2013 9:07 PM > To: Bernie Volz (volz) > Cc: Mark ZZZ Smith; Andrew Yourtchenko (ayourtch); v6ops@ietf.org > Subject: Re: [v6ops] New Version Notification for = draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >=20 >=20 > On Dec 6, 2013, at 17:25 , Bernie Volz (volz) wrote: >=20 >> Mark: >>=20 >> The difference between DHCPv6 and RA multicast is the direction. >>=20 >> DHCPv6 multicast is client to server (or relay). This has far fewer = problems in some networks because the first hop is typically on the = wired portion of the network (and the destination multicast address is = usually just joined by a few devices (relays and servers) - not all). >=20 > You should study RA a little better. >=20 >>=20 >> RA multicast is router to client(s). This has problems in = distributing the traffic out to all of the clients over some networks. >=20 >=20 > Only some RA is done this way. >=20 > Clients starting up (and/or a client whose address is close to its = lifetime) send an RS message to a multicast group joined by only a few. = There are no "hops" because this is all link-local communication. >=20 > Routers then respond either with a multicast or a unicast RA. >=20 > As such, I think this provides at least the same reliability as DHCPv6 = per your comments above, while also providing the additional robustness = you already attributed to all-hosts-multicast periodic RAs from the = routers. >=20 > Owen >=20 >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ=20 >> Smith >> Sent: Friday, December 06, 2013 8:01 PM >> To: Andrew Yourtchenko (ayourtch) >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] New Version Notification for=20 >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>=20 >>=20 >> ----- Original Message ----- >>> From: Andrew Yourtchenko >>> To: Mark ZZZ Smith >>> Cc: "v6ops@ietf.org" >>> Sent: Saturday, 7 December 2013 3:34 AM >>> Subject: Re: [v6ops] New Version Notification for=20 >>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>>=20 >>> Hi Mark, >>>=20 >>> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: >>>=20 >>>> Hi, >>>>=20 >>>> Some criticisms/comments/questions on these pieces of text=20 >>>> relating to >>> layer 2/wifi multicast reliablity: >>>>=20 >>>> "This is where the peer-to-peer, acknowledged nature of DHCPv6 may=20= >>>> be >>>> beneficial - on a crowded large-scale WiFi, without special tricks=20= >>>> to ensure the reliable delivery of multicast packets, you simply=20= >>>> will not get the SLAAC working because the multicast RAs will get=20= >>>> crunched by the interference." >>>> I'd think that if multicast is unreliable enough to cause RAs to=20= >>>> fail to be delivered often enough, then anything which relies on=20= >>>> multicast traffic is also likely to fail, which would include = neighbor discovery. >>>> So regardless of if RAs were replaced with DHCPv6, the link is not=20= >>>> going to provide reliable IPv6 operation, because IPv6 addresses=20= >>>> cannot be reliably resolved to layer 2 addresses. >>>>=20 >>>> MLD would probably fail too, so any routed multicast applications,=20= >>>> even low bandwidth ones, wouldn't work either, as would MLD=20 >>>> snooping based layer 2 forwarding optimisation. >>>>=20 >>>> DHCPv6 uses multicast for DHCPv6 server/relay discovery, so that=20= >>>> will >>> probably be unreliable as well. >>>>=20 >>>> I don't think broadcasts on wifi are reliable, so IPv4 ARP would=20= >>>> be >>> failing too. >>>>=20 >>>> So if RAs are failing because of not reliable enough multicast=20 >>>> then that is just one symptom of the link being overloaded, and=20 >>>> there will be others. >>>=20 >>> I think I capture several points here, tell me if I get them = correctly: >>>=20 >>> 1) There are other protocols that use multicast that will fail. >>=20 >> Yes.=20 >>=20 >>> 2) Fix your link. >>>=20 >>> for (1): RA is probably the only one that does not incorporate a=20 >>> robust retransmit mechanism. >>>=20 >>=20 >> In the case of multicast RAs there are two independent reliability = mechanisms used, one router side, one host side. >>=20 >> Firstly, the router lifetime in the RA is to be set to = AdvDefaultLifetime or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning = that for a host to lose knowledge of a router it has to miss 3 = unsolicited multicast RAs in a row. >>=20 >> Secondly, hosts retransmit their RSes multiple times (RFC4861, = 6.3.7). >>=20 >> I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as = they only implement the second mechanism. For DHCPv6, neighbor discovery = and MLD to be as robust as RAs, the DHCPv6 server and the hosts would = have to also issue periodically unsolicited announcements of themselves = so that other hosts and routers don't have to solicit for them, unless = they have no existing knowledge of them. >>=20 >> (Should we add the ES-IS neighbor discovery model to IPv6 ND to make = it more robust? ES-IS has hosts periodically multicast their presence to = the link's routers, routers periodically multicast their presence to the = hosts, hosts default to sending to their routers for all destinations, = then routers sends a redirects to a host when the destination host is on = the same link.). >>=20 >>=20 >>> for (2): It's great if you can, but I'd like to have protocol work = in=20 >>> all conditions. >>=20 >> That sound to me like an assertion that DHCPv6 is going to work in = all conditions. Given that DHCPv6 server discovery is less reliable than = RAs (because of the lack of unsolicited DHCPv6 server advertisements), = how is moving RA functions into DHCPv6 going to make DHCPv6 more = reliable than RAs? >>=20 >>> Especially that legacy IP does look more robust. >>=20 >>>=20 >>=20 >> So I'm curious why legacy IP is supposedly more robust? IPv4 uses = broadcasts for ARP and DHCP server discovery. On these links where IPv4 = "looks more robust" than IPv6, are broadcasts provided more reliable = delivery than multicasts, in particular as broadcasts must be flooded to = all hosts, where as multicasts can have their flooding scope limited = using MLD snooping? >>=20 >>=20 >>>=20 >>>> One idea I've had for this sort of scenario would be for the link=20= >>>> to operate as mostly an IPv6 over NBMA segment. The only multicasts=20= >>>> on the link are RAs, providing the necessary NBMA operation = parameters. >>>> It of course would require changes to clients and routers, but = then=20 >>>> again, so would using DHCPv6 for what RAs are used for today. >>>=20 >>> You can do this with no changes today. >>>=20 >>> Block traffic between the hosts (similar to private vlan), advertise=20= >>> prefixes as off-link, send all the traffic via the router on the=20 >>> wired side, block all the inbound ND from hosts except for the RS = and=20 >>> NS sent to solicited node address of the router + destined to the = router. >>>=20 >>> I tested this, it works like a charm - at least for the strawman=20 >>> browsing scenario. >>>=20 >>=20 >> Right, and doing that would solve the multicast capacity exhaustion = problems that would effect RA multicasts (and DHCPv6, ND and MLD = multicasts), because it is a more extreme case of constraining where = multicasts are sent than MLD snooping. >>=20 >> My Broadcast Multi-Access (BMA) link operating as NBMA suggestion = wouldn't require both having available and enabling any link-layer = special features to achieve the goal of significantly reducing multicast = traffic.=20 >>=20 >> (Thinking about it, the recent Efficient ND proposal is perhaps a=20 >> special case of operating a BMA link as an NBMA link for the Neighbor=20= >> Discovery protocol. I'm starting to wonder if it might be better to=20= >> just adopt this complete NBMA model over a BMA link and eliminate all=20= >> link-layer multicasts (ND, DHCPv6, MLD), except RAs to announce the=20= >> BMA link is operating in NBMA mode. The only multicasts would be=20 >> unsolicited RAs, which, for a single router, could be only once every=20= >> 30 minutes (15 minutes for two routers). I'd think that sort of=20 >> interval would be adequate to address the concerns of multicasts=20 >> consuming mobile device battery life.) >>=20 >>=20 >>>>=20 >>>> "Alternatively, in a very mobile environment and the RFC-compliant >>>>=20 >>>> router, multicast solicited RAs might make a significant portion = of >>>> your traffic - which, due to a difference in modulation, etc. may=20= >>>> eat >>>> way more bandwidth than if they were sent unicast." >>>>=20 >>>> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think if a=20= >>>> link can't handle 1 multicast every few seconds, it's also past = the=20 >>>> point >>> of >>>> it's capacity (and as above, other multicast/broadcast would also = be=20 >>>> contributing to exceeding link capacity.) >>>=20 >>> Modulation. Your multicast packets may take in the most extreme case=20= >>> 54x time more airtime than a unicast. This means 54x more = probability=20 >>> it will be dropped. Also, forget the home wireless with one AP. Now=20= >>> imagine >>> 300-500 APs having to send these packets. You have 3 frequencies on=20= >>> 2.4Ghz spectrum that you can use. So remembering that the whole=20 >>> construct is 3D, you are *bound* to have some interference. >>>=20 >>=20 >> Are all of those 300-500 APs in a single broadcast/multicast domain = i.e., one large link? That's convenient, but if multicasts/broadcasts = aren't reliable enough, that suggests the link capacity is exhausted. = Dividing the link up using routers to reduce multicast/broadcasts is and = has been the common solution since broadcast multiaccess links were = invented (which I think would be since around late 1970s when Ethernet = was invented). >>=20 >> Moving to an NBMA model by effectively modelling the BMA link as a = full mesh of virtual point-to-point links would probably be an = alternative method of overcoming multicast/broadcast capacity = limitations. >>=20 >>> So, it can be quite delicate in the most extreme cases. >>>=20 >>> And again, I want the protocol to be deployable in the most extreme=20= >>> cases >>> - especially when legacy IP survives them fine. >>>=20 >>=20 >> How does it? Legacy IP uses broadcasts.=20 >>=20 >>> Yes, not everyone will have them. >>>=20 >>> But dismissing those cases just because they do not apply to one's=20= >>> environment is incorrect. >>>=20 >>> And this is to me the whole point of the argument, which I would = like=20 >>> to get back to, instead of trying to argue about the details: >>>=20 >>> Yes, RA-only operation is *fantastic* for some circumstances. I love=20= >>> it myself and do it whenever I can because this allows me to avoid=20= >>> doing boring work. >>>=20 >>> But I may be forced to do DHCPv6. For any of the reasons already=20 >>> present in the draft, pick one. And this means I am forced to do = also=20 >>> RA, which is a pain. >>>=20 >>=20 >> So the objections I have are, >>=20 >> - I don't see how anything in DHCPv6 makes it dramatically more = reliable than RAs, given that it too uses multicasts for DHCPv6 server = discovery. Adding RA functions into DHCPv6 is described or asserted to = be the panacea to all issues that RAs could suffer from, yet analysis = shows it isn't. >>=20 >> - I think it would be better to incrementally tune and optimise the=20= >> existing designed, standardised, code developed, code debugged and=20 >> widely deployed mechanism (RAs) to overcome corner cases, and/or to=20= >> adopt past developed methods such as IPv6 over NBMA, than to spend = the=20 >> next 5 to 10 years waiting for the design, standardisation, code=20 >> development, code debugging and widespread deployment of RA functions=20= >> to be incorporated into DHCPv6, and then also have to develop methods=20= >> of conflict resolution when RAs and DHCPv6 options disagree (because=20= >> they will, unless you don't plan to transition to DHCPv6 only until=20= >> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will=20= >> have to co-exist on a link for many years if you can't demand or=20 >> guarantee DHCPv6 RA functionality from the host implementations.) >>=20 >> - Using DHCPv6 for RA functionality won't eliminate one of the = supposed causes of RA unreliability - multicast unreliability. All of = DHCPv6, neighbor discovery and MLD would have to be made more robust = against multicast unreliability to truly solve that problem. >>=20 >> - I'm for a single method that works adequately. DHCPv6 with RA = options would probably qualify if we didn't already have a existing = method. Existing methods that work are always better than non-existent = ones that need to be developed, tested and ubiquitously deployed before = they become significantly useful and can be assumed to be available. >>=20 >>=20 >>> I think the large part of the tussle comes from the people wanting = to=20 >>> make the functionality of the RA/DHCPv6 more symmetric and being = told=20 >>> "no". >>>=20 >>=20 >> The thing they need to demonstrate is that the costs of deploying a = new and second mechanism that is near functionally equivalent to the = first is worth the benefits. Given that the costs of developing and = deploying RAs has already been paid, I think the benefits of using = DHCPv6 for RA functions have to be very significant before the price = should be paid. The benefits of DHCPv6 for RA functions now needs to be = compelling. I don't think they are, otherwise I'd be quite happy to = advocate for DHCPv6 for RA functions. >>=20 >>=20 >>> And if we then tell them "Either use RA or no IPv6 for you" they say >>=20 >>> "fine, I choose no IPv6". And keep stacking on these NATs to support=20= >>> devices that "do not support IPv6" in that circumstances. >>>=20 >>=20 >> I don't think RAs are the single reason some people are resisting = deploying IPv6 at all. I think some people are resisting deploying IPv6 = because it needs to do one or both of two things for them - solve a = foreseeable problem that will effect them, or provide a tangible = benefit. If it won't do either of those things, then they don't = currently see any value from the effort involved. What are foreseeable = problems or tangible benefits is completely up to the perspective of the = decision maker. Eventually they'll see value in it, and deploy it. In = some cases, some people who could deploy IPv6 may never see any value in = deploying it, so they never will. >>=20 >> There is no single answer to why people might resist deploying IPv6, = no single solution, and things that motivate people to deploy or not = IPv6 may have nothing to do with how IPv6 itself works. >>=20 >>=20 >>=20 >>> I think in this discussion are again getting into the argument of=20 >>> "the best solution" instead of trying to collect the properties of=20= >>> the RA and DHCP. >>>=20 >>> My position is that single best solution does not exist, because >>=20 >>> everyone's problems are slightly different. So, rather than = preaching=20 >>> for everyone to adopt the single solution which is the best in one=20= >>> scenario and suboptimal in the other, we should be engineering a way=20= >>> to be able to apply different solutions in different circumstances=20= >>> without the overhead of double work. >>>=20 >>=20 >> A single solution that solves most cases is better than two = different, near functionally equivalent solutions that solve the same = cases. Multiple near-equivalent solutions create more code, more bugs = and then require conflict resolution mechanisms, creating even more code = and more bugs, with very little actual benefit. >>=20 >> There are multiple ways of solving the neighbor discovery/router = discovery/host parameter configuration problem (read Radia Perlman's = "Interconnections" book as a starting point, and then perhaps "Inside = Appletalk", and also look into Novell's IPX and Network Directory = Services.). They all have different trade-offs, but fundamentally the = trade-offs aren't significantly different or compelling. Yet because = there are multiple methods to solve these problems, does that justify = implementing all of them because they each have some minor benefits over = the others, that different people might prefer? >>=20 >> Regards, >> Mark. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Fri Dec 6 19:10:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6671AE18D for ; Fri, 6 Dec 2013 19:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.382 X-Spam-Level: * X-Spam-Status: No, score=1.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id age_m5NsXKNT for ; Fri, 6 Dec 2013 19:10:41 -0800 (PST) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) by ietfa.amsl.com (Postfix) with SMTP id 1CFD41AE197 for ; Fri, 6 Dec 2013 19:10:41 -0800 (PST) Received: from [98.139.215.141] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 03:10:37 -0000 Received: from [98.139.212.199] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 03:10:37 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 07 Dec 2013 03:10:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 995192.40662.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 39077 invoked by uid 60001); 7 Dec 2013 03:10:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1386385836; bh=F4xW+fmjI+D+r/lgQA3JTpJn5q+usOnJlMEZNVXc+2w=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cboaRJHmGwK1x1fA253OfHpqapzKzykhm9m9bQggvZyuVQqEbOj2PQrgfVFz25XqHHonpYO3Ju7HWGthZ+N45sM6Rt+r8hSL95ejaw0WNDy4U1J8uM1LcvDcdvvjG8n85EX5sPhLY78/iONT0GusNUs2P/KhyeBjgtIcyFKCo9k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0C0XQxep8vsl0UV1e5Xf0CVJOzId9jXk7yvMUapfpdZvhxpdUkuJOm7TIUXbZf5Y1RU/D9uEAmOyNZIGLtAz+hflgmpfOTLI8jnwlRf4tCIMibJKvtryviy3+6B699yqnSV0plTa8NbBZhauTGUgyyhbXfzmoZxfgPLPuMo8FK4=; X-YMail-OSG: KRkY1xoVM1lV8vkfOqcCXD.krDLS.q1wXLWNLuGEzLZCC1V UAf52F2Jo1fvH6LgW.JnrB0yCTh5diPDXYMKYHKQQR_wH16wmK9GHxGAg_cD CJa0zxoSbr8CaLj9iToesSajKDKXthRgx.1_2jiBrJZ9.cVnqLdsG3U5Rg.G vmbW2FTQw3OO8_CJx_GfEQf_OKKP57RGaf6f86_AVfT8dih.eJf3kBw4uEl0 E4cpOQibJQnB7EPTtKz9IRK5A9k7sh6iWoOqFcYe_F7yRMfKQpVp3Hw94jtI GWn3aUskCpscp.0SCLWVVBwKAInANcXDCLAFQfWVzMUfBhKOsgKdAmJZPkTi brZdBsMniCI2Vr87dGeiF2FTx5RYQuPxrY62sH_EkLazHrAFh9lIuLK7p0cG voNgXHYkSAgCfdJGMZtpqRZYjuUbo9_qtxbDAYlBloThqKcDOkKjseKP3.ey n8c.Oz_sRthG3XT_tDhPw1fpztWu0bPG1wfoZr0hN_4_raDAadsQKz.5Hgrd LbzR.x9d2VmcW_OG8vl4qXu5z3a0w4HA1d1V2xmve1uoZN.BByNuEMCiGrGW Dsgq4O0H.BBMp Received: from [150.101.221.237] by web161906.mail.bf1.yahoo.com via HTTP; Fri, 06 Dec 2013 19:10:36 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPgo.IFRvOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.IENjOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT47IEFuZHJldyBZb3VydGNoZW5rbyAoYXlvdXJ0Y2gpIDxheW91cnRjaEBjaXNjby5jb20.OyAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBTYXR1cmRheSwgNyBEZWNlbWJlciAyMDEzIDE6MjUgUE0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> Message-ID: <1386385836.88691.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Fri, 6 Dec 2013 19:10:36 -0800 (PST) From: Mark ZZZ Smith To: "Bernie Volz \(volz\)" , Owen DeLong In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 03:10:44 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Bernie Volz (volz) =0A> To: Owen DeLong =0A> Cc: Mark ZZZ Smith ; Andrew Yourtchenko (ayourtch) ; "v6ops@ietf.org" =0A> Sent: Saturday, 7 December 2013 1= :25 PM=0A> Subject: RE: [v6ops] New Version Notification for=09draft-yourtc= henko-ra-dhcpv6-comparison-00.txt (fwd)=0A> =0A> Yes, I am aware of that - = unicast RA from the router to the client is available. =0A> Just isn't clea= r now often it is used.=0A> =0A> But, this doesn't address the periodic RAs= normally sent by routers as those =0A> are multicast.=0A>=A0=0A=0AAs a rou= ter would have knowledge of the hosts it has sent unicast RAs to via its ne= ighbor cache, for the purposes of NUD, a router could periodically unicast = RAs directly to the individual hosts.=0A=0A=0ARegards,=0AMark.=0A=0A=0A> - = Bernie=0A> =0A> =0A> -----Original Message-----=0A> From: Owen DeLong [mail= to:owen@delong.com] =0A> Sent: Friday, December 06, 2013 9:07 PM=0A> To: Be= rnie Volz (volz)=0A> Cc: Mark ZZZ Smith; Andrew Yourtchenko (ayourtch); v6o= ps@ietf.org=0A> Subject: Re: [v6ops] New Version Notification for =0A> draf= t-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)=0A> =0A> =0A> On Dec 6, 201= 3, at 17:25 , Bernie Volz (volz) wrote:=0A> =0A>> Mark:= =0A>> =0A>> The difference between DHCPv6 and RA multicast is the directio= n.=0A>> =0A>> DHCPv6 multicast is client to server (or relay). This has fa= r fewer =0A> problems in some networks because the first hop is typically o= n the wired =0A> portion of the network (and the destination multicast addr= ess is usually just =0A> joined by a few devices (relays and servers) - not= all).=0A> =0A> You should study RA a little better.=0A> =0A>> =0A>> RA mu= lticast is router to client(s). This has problems in distributing the =0A> = traffic out to all of the clients over some networks.=0A> =0A> =0A> Only so= me RA is done this way.=0A> =0A> Clients starting up (and/or a client whose= address is close to its lifetime) =0A> send an RS message to a multicast g= roup joined by only a few. There are no =0A> "hops" because this is all lin= k-local communication.=0A> =0A> Routers then respond either with a multicas= t or a unicast RA.=0A> =0A> As such, I think this provides at least the sam= e reliability as DHCPv6 per your =0A> comments above, while also providing = the additional robustness you already =0A> attributed to all-hosts-multicas= t periodic RAs from the routers.=0A> =0A> Owen=0A> =0A>> =0A>> - Bernie=0A= >> =0A>> -----Original Message-----=0A>> From: v6ops [mailto:v6ops-bounce= s@ietf.org] On Behalf Of Mark ZZZ =0A>> Smith=0A>> Sent: Friday, December= 06, 2013 8:01 PM=0A>> To: Andrew Yourtchenko (ayourtch)=0A>> Cc: v6ops@i= etf.org=0A>> Subject: Re: [v6ops] New Version Notification for =0A>> draf= t-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)=0A>> =0A>> =0A>> ----- Ori= ginal Message -----=0A>>> From: Andrew Yourtchenko =0A= >>> To: Mark ZZZ Smith =0A>>> Cc: "v6ops@ietf.= org" =0A>>> Sent: Saturday, 7 December 2013 3:34 AM=0A>>> = Subject: Re: [v6ops] New Version Notification for =0A>>> draft-yourtchenk= o-ra-dhcpv6-comparison-00.txt (fwd)=0A>>> =0A>>> Hi Mark,=0A>>> =0A>>> On= Thu, 5 Dec 2013, Mark ZZZ Smith wrote:=0A>>> =0A>>>> =A0 Hi,=0A>>>> =0A>>= >> =A0 Some criticisms/comments/questions on these pieces of text =0A>>>> = relating to=0A>>> layer 2/wifi multicast reliablity:=0A>>>> =0A>>>> =A0 = "This is where the peer-to-peer, acknowledged nature of =0A> DHCPv6 may =0A= >>>> be=0A>>>> =A0 beneficial - on a crowded large-scale WiFi, without sp= ecial =0A> tricks =0A>>>> to=A0 ensure the reliable delivery of multicast = packets, you simply =0A>>>> will not=A0 get the SLAAC working because the = multicast RAs will get =0A>>>> crunched by the=A0 interference."=0A>>>> = =A0 I'd think that if multicast is unreliable enough to cause RAs =0A> to = =0A>>>> fail=A0 to be delivered often enough, then anything which relies o= n =0A>>>> multicast=A0 traffic is also likely to fail, which would include= =0A> neighbor discovery.=0A>>>> So regardless of if RAs were replaced wit= h DHCPv6, the link is not =0A>>>> going=A0 to provide reliable IPv6 operat= ion, because IPv6 addresses =0A>>>> cannot be=A0 reliably resolved to laye= r 2 addresses.=0A>>>> =0A>>>> =A0 MLD would probably fail too, so any rout= ed multicast =0A> applications, =0A>>>> even=A0 low bandwidth ones, wouldn= 't work either, as would MLD =0A>>>> snooping based=A0 layer 2 forwarding = optimisation.=0A>>>> =0A>>>> =A0 DHCPv6 uses multicast for DHCPv6 server/r= elay discovery, so that =0A>>>> will=0A>>> probably be unreliable as well= .=0A>>>> =0A>>>> =A0 I don't think broadcasts on wifi are reliable, so IPv= 4 ARP =0A> would =0A>>>> be=0A>>> failing too.=0A>>>> =0A>>>> =A0 So if = RAs are failing because of not reliable enough multicast =0A>>>> then that= is just one symptom of the link being overloaded, and =0A>>>> there will = be=A0 others.=0A>>> =0A>>> I think I capture several points here, tell me = if I get them correctly:=0A>>> =0A>>> 1) There are other protocols that us= e multicast that will fail.=0A>> =0A>> Yes. =0A>> =0A>>> 2) Fix your link= .=0A>>> =0A>>> for (1): RA is probably the only one that does not incorpor= ate a =0A>>> robust retransmit mechanism.=0A>>> =A0 =0A>> =0A>> In the ca= se of multicast RAs there are two independent reliability =0A> mechanisms u= sed, one router side, one host side.=0A>> =0A>> Firstly, the router lifeti= me in the RA is to be set to AdvDefaultLifetime =0A> or 3 * MaxRtrAdvInterv= al (RFC4861, 6.2.1), meaning that for a host to lose =0A> knowledge of a ro= uter it has to miss 3 unsolicited multicast RAs in a row.=0A>> =0A>> Secon= dly, hosts retransmit their RSes multiple times (RFC4861, 6.3.7).=0A>> =0A>= > I'd argue that DHCPv6, neighbor discovery and MLD are less robust, as = =0A> they only implement the second mechanism. For DHCPv6, neighbor discove= ry and MLD =0A> to be as robust as RAs, the DHCPv6 server and the hosts wou= ld have to also issue =0A> periodically unsolicited announcements of themse= lves so that other hosts and =0A> routers don't have to solicit for them, u= nless they have no existing =0A> knowledge of them.=0A>> =0A>> (Should we = add the ES-IS neighbor discovery model to IPv6 ND to make it =0A> more robu= st? ES-IS has hosts periodically multicast their presence to the =0A> link'= s routers, routers periodically multicast their presence to the hosts, =0A>= hosts default to sending to their routers for all destinations, then route= rs =0A> sends a redirects to a host when the destination host is on the sam= e link.).=0A>> =0A>> =0A>>> for (2): It's great if you can, but I'd like t= o have protocol =0A> work in =0A>>> all conditions.=0A>> =0A>> That sound= to me like an assertion that DHCPv6 is going to work in all =0A> condition= s. Given that DHCPv6 server discovery is less reliable than RAs =0A> (becau= se of the lack of unsolicited DHCPv6 server advertisements), how is moving = =0A> RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs?= =0A>> =0A>>> Especially that legacy IP does look more robust.=0A>> =0A>>> = =A0 =0A>> =0A>> So I'm curious why legacy IP is supposedly more robust? IP= v4 uses =0A> broadcasts for ARP and DHCP server discovery. On these links w= here IPv4 =0A> "looks more robust" than IPv6, are broadcasts provided more = reliable =0A> delivery than multicasts, in particular as broadcasts must be= flooded to all =0A> hosts, where as multicasts can have their flooding sco= pe limited using MLD =0A> snooping?=0A>> =0A>> =0A>>> =0A>>>> =A0 One idea= I've had for this sort of scenario would be for the =0A> link =0A>>>> to = operate as mostly an IPv6 over NBMA segment. The only multicasts =0A> =0A>>= >> on the=A0 link are RAs, providing the necessary NBMA operation =0A> par= ameters.=0A>>>> It of=A0 course would require changes to clients and route= rs, but =0A> then =0A>>>> again, so=A0 would using DHCPv6 for what RAs are= used for today.=0A>>> =0A>>> You can do this with no changes today.=0A>>>= =0A>>> Block traffic between the hosts (similar to private vlan), adverti= se =0A>>> prefixes as off-link, send all the traffic via the router on the= =0A>>> wired side, block all the inbound ND from hosts except for the RS = and =0A>>> NS sent to solicited node address of the router + destined to t= he =0A> router.=0A>>> =0A>>> I tested this, it works like a charm - at lea= st for the strawman =0A>>> browsing scenario.=0A>>> =A0 =0A>> =0A>> Right= , and doing that would solve the multicast capacity exhaustion =0A> problem= s that would effect RA multicasts (and DHCPv6, ND and MLD multicasts), =0A>= because it is a more extreme case of constraining where multicasts are sen= t than =0A> MLD snooping.=0A>> =0A>> My Broadcast Multi-Access (BMA) link = operating as NBMA suggestion =0A> wouldn't require both having available an= d enabling any link-layer special =0A> features to achieve the goal of sign= ificantly reducing multicast traffic. =0A>> =0A>> (Thinking about it, the = recent Efficient ND proposal is perhaps a =0A>> special case of operating = a BMA link as an NBMA link for the Neighbor =0A>> Discovery protocol. I'm = starting to wonder if it might be better to =0A>> just adopt this complete= NBMA model over a BMA link and eliminate all =0A>> link-layer multicasts = (ND, DHCPv6, MLD), except RAs to announce the =0A>> BMA link is operating = in NBMA mode. The only multicasts would be =0A>> unsolicited RAs, which, f= or a single router, could be only once every =0A>> 30 minutes (15 minutes = for two routers). I'd think that sort of =0A>> interval would be adequate = to address the concerns of multicasts =0A>> consuming mobile device batter= y life.)=0A>> =0A>> =0A>>>> =0A>>>> =A0 "Alternatively, in a very mobile e= nvironment and the =0A> RFC-compliant=0A>>>> =0A>>>> =A0 router, multicast= solicited RAs might make a significant portion =0A> of=0A>>>> =A0 your tr= affic - which, due to a difference in modulation, etc.=A0 =0A> may =0A>>>> = eat=0A>>>> =A0 way more bandwidth than if they were sent unicast."=0A>>>>= =0A>>>> =A0 The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think = =0A> if a =0A>>>> link=A0 can't handle 1 multicast every few seconds, it's= also =0A> past the =0A>>>> point=0A>>> of=0A>>>> it's capacity (and as = above, other multicast/broadcast would =0A> also be =0A>>>> contributing t= o exceeding link capacity.)=0A>>> =0A>>> Modulation. Your multicast packet= s may take in the most extreme case =0A>>> 54x time more airtime than a un= icast. This means 54x more probability =0A>>> it will be dropped. Also, fo= rget the home wireless with one AP. Now =0A>>> imagine=0A>>> 300-500 APs = having to send these packets. You have 3 frequencies on =0A>>> 2.4Ghz spec= trum that you can use. So remembering that the whole =0A>>> construct is 3= D, you are *bound* to have some interference.=0A>>> =A0 =0A>> =0A>> Are al= l of those 300-500 APs in a single broadcast/multicast domain i.e., =0A> on= e large link? That's convenient, but if multicasts/broadcasts aren't =0A> r= eliable enough, that suggests the link capacity is exhausted. Dividing the = link =0A> up using routers to reduce multicast/broadcasts is and has been t= he common =0A> solution since broadcast multiaccess links were invented (wh= ich I think would be =0A> since around late 1970s when Ethernet was invente= d).=0A>> =0A>> Moving to an NBMA model by effectively modelling the BMA li= nk as a full =0A> mesh of virtual point-to-point links would probably be an= alternative method of =0A> overcoming multicast/broadcast capacity limitat= ions.=0A>> =0A>>> So, it can be quite delicate in the most extreme cases.= =0A>>> =0A>>> And again, I want the protocol to be deployable in the most = extreme =0A>>> cases=0A>>> - especially when legacy IP survives them fine= .=0A>>> =A0 =0A>> =0A>> How does it? Legacy IP uses broadcasts. =0A>> =0A>= >> Yes, not everyone will have them.=0A>>> =0A>>> But dismissing those ca= ses just because they do not apply to one's =0A>>> environment is incorrec= t.=0A>>> =0A>>> And this is to me the whole point of the argument, which I= would like =0A>>> to get back to, instead of trying to argue about the de= tails:=0A>>> =0A>>> Yes, RA-only operation is *fantastic* for some circums= tances. I love =0A>>> it myself and do it whenever I can because this allo= ws me to avoid =0A>>> doing boring work.=0A>>> =0A>>> But I may be forced= to do DHCPv6. For any of the reasons already =0A>>> present in the draft,= pick one. And this means I am forced to do also =0A>>> RA, which is a pai= n.=0A>>> =A0 =0A>> =0A>> So the objections I have are,=0A>> =0A>> - I don= 't see how anything in DHCPv6 makes it dramatically more =0A> reliable than= RAs, given that it too uses multicasts for DHCPv6 server =0A> discovery. A= dding RA functions into DHCPv6 is described or asserted to be the =0A> pana= cea to all issues that RAs could suffer from, yet analysis shows it =0A> is= n't.=0A>> =0A>> - I think it would be better to incrementally tune and opt= imise the =0A>> existing designed, standardised, code developed, code debu= gged and =0A>> widely deployed mechanism (RAs) to overcome corner cases, a= nd/or to =0A>> adopt past developed methods such as IPv6 over NBMA, than t= o spend the =0A>> next 5 to 10 years waiting for the design, standardisati= on, code =0A>> development, code debugging and widespread deployment of RA= functions =0A>> to be incorporated into DHCPv6, and then also have to dev= elop methods =0A>> of conflict resolution when RAs and DHCPv6 options disa= gree (because =0A>> they will, unless you don't plan to transition to DHCP= v6 only until =0A>> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA = functions will =0A>> have to co-exist on a link for many years if you can'= t demand or =0A>> guarantee DHCPv6 RA functionality from the host implemen= tations.)=0A>> =0A>> - Using DHCPv6 for RA functionality won't eliminate o= ne of the supposed =0A> causes of RA unreliability - multicast unreliabilit= y. All of DHCPv6, neighbor =0A> discovery and MLD would have to be made mor= e robust against multicast =0A> unreliability to truly solve that problem.= =0A>> =0A>> - I'm for a single method that works adequately. DHCPv6 with R= A options =0A> would probably qualify if we didn't already have a existing = method. Existing =0A> methods that work are always better than non-existent= ones that need to be =0A> developed, tested and ubiquitously deployed befo= re they become significantly =0A> useful and can be assumed to be available= .=0A>> =0A>> =0A>>> I think the large part of the tussle comes from the pe= ople wanting to =0A>>> make the functionality of the RA/DHCPv6 more symmet= ric and being told =0A>>> "no".=0A>>> =A0 =0A>> =0A>> The thing they need= to demonstrate is that the costs of deploying a new and =0A> second mechan= ism that is near functionally equivalent to the first is worth the =0A> ben= efits. Given that the costs of developing and deploying RAs has already bee= n =0A> paid, I think the benefits of using DHCPv6 for RA functions have to = be very =0A> significant before the price should be paid. The benefits of D= HCPv6 for RA =0A> functions now needs to be compelling. I don't think they = are, otherwise =0A> I'd be quite happy to advocate for DHCPv6 for RA functi= ons.=0A>> =0A>> =0A>>> And if we then tell them "Either use RA or no IPv6 = for you" =0A> they say=0A>> =0A>>> "fine, I choose no IPv6". And keep stac= king on these NATs to =0A> support =0A>>> devices that "do not support IPv= 6" in that circumstances.=0A>>> =A0 =0A>> =0A>> I don't think RAs are the = single reason some people are resisting =0A> deploying IPv6 at all. I think= some people are resisting deploying IPv6 because =0A> it needs to do one o= r both of two things for them - solve a foreseeable problem =0A> that will = effect them, or provide a tangible benefit. If it won't do either =0A> of t= hose things, then they don't currently see any value from the effort =0A> i= nvolved. What are foreseeable problems or tangible benefits is completely u= p to =0A> the perspective of the decision maker. Eventually they'll see val= ue in it, =0A> and deploy it. In some cases, some people who could deploy I= Pv6 may never see =0A> any value in deploying it, so they never will.=0A>> = =0A>> There is no single answer to why people might resist deploying IPv6,= no =0A> single solution, and things that motivate people to deploy or not = IPv6 may have =0A> nothing to do with how IPv6 itself works.=0A>> =0A>> =0A= >> =0A>>> I think in this discussion are again getting into the argument o= f =0A>>> "the best solution" instead of trying to collect the =0A> propert= ies of =0A>>> the RA and DHCP.=0A>>> =A0 =0A>>> My position is that singl= e best solution does not exist, because=0A>> =0A>>> everyone's problems ar= e slightly different. So, rather than =0A> preaching =0A>>> for everyone t= o adopt the single solution which is the best in one =0A>>> scenario and s= uboptimal in the other, we should be engineering a way =0A>>> to be able t= o apply different solutions in different circumstances =0A>>> without the = overhead of double work.=0A>>> =A0 =0A>> =0A>> A single solution that solv= es most cases is better than two different, near =0A> functionally equivale= nt solutions that solve the same cases. Multiple =0A> near-equivalent solut= ions create more code, more bugs and then require conflict =0A> resolution = mechanisms, creating even more code and more bugs, with very little =0A> ac= tual benefit.=0A>> =0A>> There are multiple ways of solving the neighbor d= iscovery/router =0A> discovery/host parameter configuration problem (read R= adia Perlman's =0A> "Interconnections" book as a starting point, and then p= erhaps =0A> "Inside Appletalk", and also look into Novell's IPX and Network= =0A> Directory Services.). They all have different trade-offs, but fundame= ntally the =0A> trade-offs aren't significantly different or compelling. Ye= t because there =0A> are multiple methods to solve these problems, does tha= t justify implementing all =0A> of them because they each have some minor b= enefits over the others, that =0A> different people might prefer?=0A>> =0A>= > Regards,=0A>> Mark.=0A>> _____________________________________________= __=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org= /mailman/listinfo/v6ops=0A>> _____________________________________________= __=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org= /mailman/listinfo/v6ops=0A> From ayourtch@cisco.com Sat Dec 7 11:56:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957D31AE00B for ; Sat, 7 Dec 2013 11:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voZbsSeqJCQ8 for ; Sat, 7 Dec 2013 11:56:11 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4791ADF99 for ; Sat, 7 Dec 2013 11:56:10 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB7Ju5mc004122 for ; Sat, 7 Dec 2013 20:56:05 +0100 (CET) Received: from ams-ayourtch-8711.cisco.com (ams-ayourtch-8711.cisco.com [10.55.144.242]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB7Ju03I006479; Sat, 7 Dec 2013 20:56:01 +0100 (CET) Date: Sat, 7 Dec 2013 20:56:02 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Mark ZZZ Smith In-Reply-To: <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-944317968-1386446164=:68814" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 19:56:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-944317968-1386446164=:68814 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 6 Dec 2013, Mark ZZZ Smith wrote: [snip] > > So the objections I have are, > > - I don't see how anything in DHCPv6 makes it dramatically more >reliable than RAs, given that it too uses multicasts for DHCPv6 server >discovery. Adding RA functions into DHCPv6 is described or asserted to be >the panacea to all issues that RAs could suffer from, yet analysis shows >it isn't. Adding RA functions to DHCP allows to get rid of RAs for the scenarios where you have to run DHCP, plain and simple. > > - I think it would be better to incrementally tune and optimise the >existing designed, standardised, code developed, code debugged and widely >deployed mechanism (RAs) to overcome corner cases, and/or to adopt past >developed methods such as IPv6 over NBMA, than to spend the next 5 to 10 >years waiting for the design, standardisation, code development, code >debugging and widespread deployment of RA functions to be incorporated >into DHCPv6, and then also have to develop methods of conflict resolution >when RAs and DHCPv6 options disagree (because they will, unless you don't >plan to transition to DHCPv6 only until DHCPv6 RA functions are >ubiquitous. RAs and DHCPv6 RA functions will have to co-exist on a link >for many years if you can't demand or guarantee DHCPv6 RA functionality >from the host implementations.) Conflict resolution is simple: fix your network. You are describing as a problem what isn't. The http://xkcd.com/927/ is indeed a problem. But, this is a question of engineering, and using that as a blanket argument against DHCP-only operation is incorrect. > > - Using DHCPv6 for RA functionality won't eliminate one of the supposed >causes of RA unreliability - multicast unreliability. All of DHCPv6, >neighbor discovery and MLD would have to be made more robust against >multicast unreliability to truly solve that problem. Gee, we are stuck on the strawman ureliability - there are *other* reasons why one would want to use DHCP, thus being forced to run multiple protocols. > > - I'm for a single method that works adequately. DHCPv6 with RA options >would probably qualify if we didn't already have a existing method. >Existing methods that work are always better than non-existent ones that >need to be developed, tested and ubiquitously deployed before they become >significantly useful and can be assumed to be available. > > >> I think the large part of the tussle comes from the people wanting to >> make the functionality of the RA/DHCPv6 more symmetric and being told >> "no". >> > > The thing they need to demonstrate is that the costs of deploying a new >and second mechanism that is near functionally equivalent to the first is >worth the benefits. Given that the costs of developing and deploying RAs >has already been paid, I think the benefits of using DHCPv6 for RA >functions have to be very significant before the price should be paid. >The benefits of DHCPv6 for RA functions now needs to be compelling. I >don't think they are, otherwise I'd be quite happy to advocate for DHCPv6 >for RA functions. For some, the benefit would be significant. For some - it won't be any benefit at all. > > >> And if we then tell them "Either use RA or no IPv6 for you" they say > >> "fine, I choose no IPv6". And keep stacking on these NATs to support >> devices that "do not support IPv6" in that circumstances. >> > > I don't think RAs are the single reason some people are resisting >deploying IPv6 at all. I think some people are resisting deploying IPv6 >because it needs to do one or both of two things for them - solve a >foreseeable problem that will effect them, or provide a tangible benefit. >If it won't do either of those things, then they don't currently see any >value from the effort involved. What are foreseeable problems or tangible >benefits is completely up to the perspective of the decision maker. >Eventually they'll see value in it, and deploy it. In some cases, some >people who could deploy IPv6 may never see any value in deploying it, so >they never will. It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes, and the amount of pain that the big change in the network like adding a new protocol causes. As soon as the first number is smaller than the second one, nothing gets done. Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6. > > There is no single answer to why people might resist deploying IPv6, no single solution, and things that motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works. > > > >> I think in this discussion are again getting into the argument of "the >> best solution" instead of trying to collect the properties of the RA and >> DHCP. >> >> My position is that single best solution does not exist, because > >> everyone's problems are slightly different. So, rather than preaching for >> everyone to adopt the single solution which is the best in one scenario >> and suboptimal in the other, we should be engineering a way to be able to >> apply different solutions in different circumstances without the >> overhead of double work. >> > > A single solution that solves most cases is better than two different, That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that. --a >near functionally equivalent solutions that solve the same cases. >Multiple near-equivalent solutions create more code, more bugs and then >require conflict resolution mechanisms, creating even more code and more >bugs, with very little actual benefit. > > There are multiple ways of solving the neighbor discovery/router >discovery/host parameter configuration problem (read Radia Perlman's >"Interconnections" book as a starting point, and then perhaps "Inside >Appletalk", and also look into Novell's IPX and Network Directory >Services.). They all have different trade-offs, but fundamentally the >trade-offs aren't significantly different or compelling. Yet because >there are multiple methods to solve these problems, does that justify >implementing all of them because they each have some minor benefits over >the others, that different people might prefer? > > Regards, > Mark. > --0-944317968-1386446164=:68814-- From owen@delong.com Sat Dec 7 13:07:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0252A1AE416 for ; Sat, 7 Dec 2013 13:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUro5IR3MqWD for ; Sat, 7 Dec 2013 13:07:49 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF0F1AE412 for ; Sat, 7 Dec 2013 13:07:48 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB7L6IXk032315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Dec 2013 13:06:18 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB7L6IXk032315 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386450379; bh=gLAlX1trN1AftR8uD2cIcR3NdFE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=5XcTABeu9Wr3wuT8NchonRkV4cSptHmEmIwnvG2bSxtuFcF7z6bM2+A65F18iP+Th Zun3MZ8SQLoHmrhGMzzt7fi+9htrfwcY01MV5Md79yprCAzDov/p8ndrWA4ih+0e5W uFmVBqVUGs4oY2y1miJKrd3c0d8slGhOu+ofgbqU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <1386385836.88691.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Sat, 7 Dec 2013 13:05:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2B3AF247-B5CB-4A4A-878E-B9C17983CBC6@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> <1386385836.88691.YahooMailNeo@web161906.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 07 Dec 2013 13:06:19 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 21:07:52 -0000 I don't see a need for or benefit from doing so. I think unicast RAs = should only be sent in response to RS. I do see a valid use case for hosts sending RS if they are getting close = to their desired or valid timers. Owen On Dec 6, 2013, at 19:10 , Mark ZZZ Smith = wrote: >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Bernie Volz (volz) >> To: Owen DeLong >> Cc: Mark ZZZ Smith ; Andrew Yourtchenko = (ayourtch) ; "v6ops@ietf.org" >> Sent: Saturday, 7 December 2013 1:25 PM >> Subject: RE: [v6ops] New Version Notification for = draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>=20 >> Yes, I am aware of that - unicast RA from the router to the client is = available.=20 >> Just isn't clear now often it is used. >>=20 >> But, this doesn't address the periodic RAs normally sent by routers = as those=20 >> are multicast. >> =20 >=20 > As a router would have knowledge of the hosts it has sent unicast RAs = to via its neighbor cache, for the purposes of NUD, a router could = periodically unicast RAs directly to the individual hosts. >=20 >=20 > Regards, > Mark. >=20 >=20 >> - Bernie >>=20 >>=20 >> -----Original Message----- >> From: Owen DeLong [mailto:owen@delong.com]=20 >> Sent: Friday, December 06, 2013 9:07 PM >> To: Bernie Volz (volz) >> Cc: Mark ZZZ Smith; Andrew Yourtchenko (ayourtch); v6ops@ietf.org >> Subject: Re: [v6ops] New Version Notification for=20 >> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>=20 >>=20 >> On Dec 6, 2013, at 17:25 , Bernie Volz (volz) wrote: >>=20 >>> Mark: >>>=20 >>> The difference between DHCPv6 and RA multicast is the direction. >>>=20 >>> DHCPv6 multicast is client to server (or relay). This has far fewer=20= >> problems in some networks because the first hop is typically on the = wired=20 >> portion of the network (and the destination multicast address is = usually just=20 >> joined by a few devices (relays and servers) - not all). >>=20 >> You should study RA a little better. >>=20 >>>=20 >>> RA multicast is router to client(s). This has problems in = distributing the=20 >> traffic out to all of the clients over some networks. >>=20 >>=20 >> Only some RA is done this way. >>=20 >> Clients starting up (and/or a client whose address is close to its = lifetime)=20 >> send an RS message to a multicast group joined by only a few. There = are no=20 >> "hops" because this is all link-local communication. >>=20 >> Routers then respond either with a multicast or a unicast RA. >>=20 >> As such, I think this provides at least the same reliability as = DHCPv6 per your=20 >> comments above, while also providing the additional robustness you = already=20 >> attributed to all-hosts-multicast periodic RAs from the routers. >>=20 >> Owen >>=20 >>>=20 >>> - Bernie >>>=20 >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ=20 >>> Smith >>> Sent: Friday, December 06, 2013 8:01 PM >>> To: Andrew Yourtchenko (ayourtch) >>> Cc: v6ops@ietf.org >>> Subject: Re: [v6ops] New Version Notification for=20 >>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>>=20 >>>=20 >>> ----- Original Message ----- >>>> From: Andrew Yourtchenko >>>> To: Mark ZZZ Smith >>>> Cc: "v6ops@ietf.org" >>>> Sent: Saturday, 7 December 2013 3:34 AM >>>> Subject: Re: [v6ops] New Version Notification for=20 >>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>>>=20 >>>> Hi Mark, >>>>=20 >>>> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> Some criticisms/comments/questions on these pieces of text=20 >>>>> relating to >>>> layer 2/wifi multicast reliablity: >>>>>=20 >>>>> "This is where the peer-to-peer, acknowledged nature of=20 >> DHCPv6 may=20 >>>>> be >>>>> beneficial - on a crowded large-scale WiFi, without special=20 >> tricks=20 >>>>> to ensure the reliable delivery of multicast packets, you simply=20= >>>>> will not get the SLAAC working because the multicast RAs will get=20= >>>>> crunched by the interference." >>>>> I'd think that if multicast is unreliable enough to cause RAs=20= >> to=20 >>>>> fail to be delivered often enough, then anything which relies on=20= >>>>> multicast traffic is also likely to fail, which would include=20 >> neighbor discovery. >>>>> So regardless of if RAs were replaced with DHCPv6, the link is not=20= >>>>> going to provide reliable IPv6 operation, because IPv6 addresses=20= >>>>> cannot be reliably resolved to layer 2 addresses. >>>>>=20 >>>>> MLD would probably fail too, so any routed multicast=20 >> applications,=20 >>>>> even low bandwidth ones, wouldn't work either, as would MLD=20 >>>>> snooping based layer 2 forwarding optimisation. >>>>>=20 >>>>> DHCPv6 uses multicast for DHCPv6 server/relay discovery, so = that=20 >>>>> will >>>> probably be unreliable as well. >>>>>=20 >>>>> I don't think broadcasts on wifi are reliable, so IPv4 ARP=20 >> would=20 >>>>> be >>>> failing too. >>>>>=20 >>>>> So if RAs are failing because of not reliable enough multicast=20= >>>>> then that is just one symptom of the link being overloaded, and=20 >>>>> there will be others. >>>>=20 >>>> I think I capture several points here, tell me if I get them = correctly: >>>>=20 >>>> 1) There are other protocols that use multicast that will fail. >>>=20 >>> Yes.=20 >>>=20 >>>> 2) Fix your link. >>>>=20 >>>> for (1): RA is probably the only one that does not incorporate a=20 >>>> robust retransmit mechanism. >>>> =20 >>>=20 >>> In the case of multicast RAs there are two independent reliability=20= >> mechanisms used, one router side, one host side. >>>=20 >>> Firstly, the router lifetime in the RA is to be set to = AdvDefaultLifetime=20 >> or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a host to = lose=20 >> knowledge of a router it has to miss 3 unsolicited multicast RAs in a = row. >>>=20 >>> Secondly, hosts retransmit their RSes multiple times (RFC4861, = 6.3.7). >>>=20 >>> I'd argue that DHCPv6, neighbor discovery and MLD are less robust, = as=20 >> they only implement the second mechanism. For DHCPv6, neighbor = discovery and MLD=20 >> to be as robust as RAs, the DHCPv6 server and the hosts would have to = also issue=20 >> periodically unsolicited announcements of themselves so that other = hosts and=20 >> routers don't have to solicit for them, unless they have no existing=20= >> knowledge of them. >>>=20 >>> (Should we add the ES-IS neighbor discovery model to IPv6 ND to make = it=20 >> more robust? ES-IS has hosts periodically multicast their presence to = the=20 >> link's routers, routers periodically multicast their presence to the = hosts,=20 >> hosts default to sending to their routers for all destinations, then = routers=20 >> sends a redirects to a host when the destination host is on the same = link.). >>>=20 >>>=20 >>>> for (2): It's great if you can, but I'd like to have protocol=20 >> work in=20 >>>> all conditions. >>>=20 >>> That sound to me like an assertion that DHCPv6 is going to work in = all=20 >> conditions. Given that DHCPv6 server discovery is less reliable than = RAs=20 >> (because of the lack of unsolicited DHCPv6 server advertisements), = how is moving=20 >> RA functions into DHCPv6 going to make DHCPv6 more reliable than RAs? >>>=20 >>>> Especially that legacy IP does look more robust. >>>=20 >>>> =20 >>>=20 >>> So I'm curious why legacy IP is supposedly more robust? IPv4 uses=20 >> broadcasts for ARP and DHCP server discovery. On these links where = IPv4=20 >> "looks more robust" than IPv6, are broadcasts provided more reliable=20= >> delivery than multicasts, in particular as broadcasts must be flooded = to all=20 >> hosts, where as multicasts can have their flooding scope limited = using MLD=20 >> snooping? >>>=20 >>>=20 >>>>=20 >>>>> One idea I've had for this sort of scenario would be for the=20 >> link=20 >>>>> to operate as mostly an IPv6 over NBMA segment. The only = multicasts=20 >>=20 >>>>> on the link are RAs, providing the necessary NBMA operation=20 >> parameters. >>>>> It of course would require changes to clients and routers, but=20 >> then=20 >>>>> again, so would using DHCPv6 for what RAs are used for today. >>>>=20 >>>> You can do this with no changes today. >>>>=20 >>>> Block traffic between the hosts (similar to private vlan), = advertise=20 >>>> prefixes as off-link, send all the traffic via the router on the=20 >>>> wired side, block all the inbound ND from hosts except for the RS = and=20 >>>> NS sent to solicited node address of the router + destined to the=20= >> router. >>>>=20 >>>> I tested this, it works like a charm - at least for the strawman=20 >>>> browsing scenario. >>>> =20 >>>=20 >>> Right, and doing that would solve the multicast capacity exhaustion=20= >> problems that would effect RA multicasts (and DHCPv6, ND and MLD = multicasts),=20 >> because it is a more extreme case of constraining where multicasts = are sent than=20 >> MLD snooping. >>>=20 >>> My Broadcast Multi-Access (BMA) link operating as NBMA suggestion=20 >> wouldn't require both having available and enabling any link-layer = special=20 >> features to achieve the goal of significantly reducing multicast = traffic.=20 >>>=20 >>> (Thinking about it, the recent Efficient ND proposal is perhaps a=20 >>> special case of operating a BMA link as an NBMA link for the = Neighbor=20 >>> Discovery protocol. I'm starting to wonder if it might be better to=20= >>> just adopt this complete NBMA model over a BMA link and eliminate = all=20 >>> link-layer multicasts (ND, DHCPv6, MLD), except RAs to announce the=20= >>> BMA link is operating in NBMA mode. The only multicasts would be=20 >>> unsolicited RAs, which, for a single router, could be only once = every=20 >>> 30 minutes (15 minutes for two routers). I'd think that sort of=20 >>> interval would be adequate to address the concerns of multicasts=20 >>> consuming mobile device battery life.) >>>=20 >>>=20 >>>>>=20 >>>>> "Alternatively, in a very mobile environment and the=20 >> RFC-compliant >>>>>=20 >>>>> router, multicast solicited RAs might make a significant = portion=20 >> of >>>>> your traffic - which, due to a difference in modulation, etc. =20= >> may=20 >>>>> eat >>>>> way more bandwidth than if they were sent unicast." >>>>>=20 >>>>> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think=20 >> if a=20 >>>>> link can't handle 1 multicast every few seconds, it's also=20 >> past the=20 >>>>> point >>>> of >>>>> it's capacity (and as above, other multicast/broadcast would=20 >> also be=20 >>>>> contributing to exceeding link capacity.) >>>>=20 >>>> Modulation. Your multicast packets may take in the most extreme = case=20 >>>> 54x time more airtime than a unicast. This means 54x more = probability=20 >>>> it will be dropped. Also, forget the home wireless with one AP. Now=20= >>>> imagine >>>> 300-500 APs having to send these packets. You have 3 frequencies on=20= >>>> 2.4Ghz spectrum that you can use. So remembering that the whole=20 >>>> construct is 3D, you are *bound* to have some interference. >>>> =20 >>>=20 >>> Are all of those 300-500 APs in a single broadcast/multicast domain = i.e.,=20 >> one large link? That's convenient, but if multicasts/broadcasts = aren't=20 >> reliable enough, that suggests the link capacity is exhausted. = Dividing the link=20 >> up using routers to reduce multicast/broadcasts is and has been the = common=20 >> solution since broadcast multiaccess links were invented (which I = think would be=20 >> since around late 1970s when Ethernet was invented). >>>=20 >>> Moving to an NBMA model by effectively modelling the BMA link as a = full=20 >> mesh of virtual point-to-point links would probably be an alternative = method of=20 >> overcoming multicast/broadcast capacity limitations. >>>=20 >>>> So, it can be quite delicate in the most extreme cases. >>>>=20 >>>> And again, I want the protocol to be deployable in the most extreme=20= >>>> cases >>>> - especially when legacy IP survives them fine. >>>> =20 >>>=20 >>> How does it? Legacy IP uses broadcasts.=20 >>>=20 >>>> Yes, not everyone will have them. >>>>=20 >>>> But dismissing those cases just because they do not apply to one's=20= >>>> environment is incorrect. >>>>=20 >>>> And this is to me the whole point of the argument, which I would = like=20 >>>> to get back to, instead of trying to argue about the details: >>>>=20 >>>> Yes, RA-only operation is *fantastic* for some circumstances. I = love=20 >>>> it myself and do it whenever I can because this allows me to avoid=20= >>>> doing boring work. >>>>=20 >>>> But I may be forced to do DHCPv6. For any of the reasons already=20 >>>> present in the draft, pick one. And this means I am forced to do = also=20 >>>> RA, which is a pain. >>>> =20 >>>=20 >>> So the objections I have are, >>>=20 >>> - I don't see how anything in DHCPv6 makes it dramatically more=20 >> reliable than RAs, given that it too uses multicasts for DHCPv6 = server=20 >> discovery. Adding RA functions into DHCPv6 is described or asserted = to be the=20 >> panacea to all issues that RAs could suffer from, yet analysis shows = it=20 >> isn't. >>>=20 >>> - I think it would be better to incrementally tune and optimise the=20= >>> existing designed, standardised, code developed, code debugged and=20= >>> widely deployed mechanism (RAs) to overcome corner cases, and/or to=20= >>> adopt past developed methods such as IPv6 over NBMA, than to spend = the=20 >>> next 5 to 10 years waiting for the design, standardisation, code=20 >>> development, code debugging and widespread deployment of RA = functions=20 >>> to be incorporated into DHCPv6, and then also have to develop = methods=20 >>> of conflict resolution when RAs and DHCPv6 options disagree (because=20= >>> they will, unless you don't plan to transition to DHCPv6 only until=20= >>> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will=20= >>> have to co-exist on a link for many years if you can't demand or=20 >>> guarantee DHCPv6 RA functionality from the host implementations.) >>>=20 >>> - Using DHCPv6 for RA functionality won't eliminate one of the = supposed=20 >> causes of RA unreliability - multicast unreliability. All of DHCPv6, = neighbor=20 >> discovery and MLD would have to be made more robust against multicast=20= >> unreliability to truly solve that problem. >>>=20 >>> - I'm for a single method that works adequately. DHCPv6 with RA = options=20 >> would probably qualify if we didn't already have a existing method. = Existing=20 >> methods that work are always better than non-existent ones that need = to be=20 >> developed, tested and ubiquitously deployed before they become = significantly=20 >> useful and can be assumed to be available. >>>=20 >>>=20 >>>> I think the large part of the tussle comes from the people wanting = to=20 >>>> make the functionality of the RA/DHCPv6 more symmetric and being = told=20 >>>> "no". >>>> =20 >>>=20 >>> The thing they need to demonstrate is that the costs of deploying a = new and=20 >> second mechanism that is near functionally equivalent to the first is = worth the=20 >> benefits. Given that the costs of developing and deploying RAs has = already been=20 >> paid, I think the benefits of using DHCPv6 for RA functions have to = be very=20 >> significant before the price should be paid. The benefits of DHCPv6 = for RA=20 >> functions now needs to be compelling. I don't think they are, = otherwise=20 >> I'd be quite happy to advocate for DHCPv6 for RA functions. >>>=20 >>>=20 >>>> And if we then tell them "Either use RA or no IPv6 for you"=20 >> they say >>>=20 >>>> "fine, I choose no IPv6". And keep stacking on these NATs to=20 >> support=20 >>>> devices that "do not support IPv6" in that circumstances. >>>> =20 >>>=20 >>> I don't think RAs are the single reason some people are resisting=20 >> deploying IPv6 at all. I think some people are resisting deploying = IPv6 because=20 >> it needs to do one or both of two things for them - solve a = foreseeable problem=20 >> that will effect them, or provide a tangible benefit. If it won't do = either=20 >> of those things, then they don't currently see any value from the = effort=20 >> involved. What are foreseeable problems or tangible benefits is = completely up to=20 >> the perspective of the decision maker. Eventually they'll see value = in it,=20 >> and deploy it. In some cases, some people who could deploy IPv6 may = never see=20 >> any value in deploying it, so they never will. >>>=20 >>> There is no single answer to why people might resist deploying IPv6, = no=20 >> single solution, and things that motivate people to deploy or not = IPv6 may have=20 >> nothing to do with how IPv6 itself works. >>>=20 >>>=20 >>>=20 >>>> I think in this discussion are again getting into the argument of=20= >>>> "the best solution" instead of trying to collect the=20 >> properties of=20 >>>> the RA and DHCP. >>>> =20 >>>> My position is that single best solution does not exist, because >>>=20 >>>> everyone's problems are slightly different. So, rather than=20 >> preaching=20 >>>> for everyone to adopt the single solution which is the best in one=20= >>>> scenario and suboptimal in the other, we should be engineering a = way=20 >>>> to be able to apply different solutions in different circumstances=20= >>>> without the overhead of double work. >>>> =20 >>>=20 >>> A single solution that solves most cases is better than two = different, near=20 >> functionally equivalent solutions that solve the same cases. Multiple=20= >> near-equivalent solutions create more code, more bugs and then = require conflict=20 >> resolution mechanisms, creating even more code and more bugs, with = very little=20 >> actual benefit. >>>=20 >>> There are multiple ways of solving the neighbor discovery/router=20 >> discovery/host parameter configuration problem (read Radia Perlman's=20= >> "Interconnections" book as a starting point, and then perhaps=20 >> "Inside Appletalk", and also look into Novell's IPX and Network=20 >> Directory Services.). They all have different trade-offs, but = fundamentally the=20 >> trade-offs aren't significantly different or compelling. Yet because = there=20 >> are multiple methods to solve these problems, does that justify = implementing all=20 >> of them because they each have some minor benefits over the others, = that=20 >> different people might prefer? >>>=20 >>> Regards, >>> Mark. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From owen@delong.com Sat Dec 7 13:27:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D01AE424 for ; Sat, 7 Dec 2013 13:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91S2SQQMkBYt for ; Sat, 7 Dec 2013 13:27:24 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6422D1AE422 for ; Sat, 7 Dec 2013 13:27:24 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB7LO7eS032573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Dec 2013 13:24:07 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB7LO7eS032573 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386451447; bh=ot0YCruiyIWPpDWNMOGBCjeMXOc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KirFIqlA8YyQFJukHmaFXkhvhHAarB6d61HpOPB1zjh2Z0vz0vvLZ96QNFBlVWZEL SXmpMRcxbcOHrwe+L9WdxEZtjanEQjjpouYAB0ds9QY15FfeG4lsxwJ0vfSSCCFH6q HMgfi3GUB0mPzLs+ef8z/qT3kViXHg4kQKJ6cBT4= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: Date: Sat, 7 Dec 2013 13:22:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 07 Dec 2013 13:24:07 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 21:27:26 -0000 >> I don't think RAs are the single reason some people are resisting = deploying IPv6 at all. I think some people are resisting deploying IPv6 = because it needs to do one or both of two things for them - solve a = foreseeable problem that will effect them, or provide a tangible = benefit. If it won't do either of those things, then they don't = currently see any value from the effort involved. What are foreseeable = problems or tangible benefits is completely up to the perspective of the = decision maker. Eventually they'll see value in it, and deploy it. In = some cases, some people who could deploy IPv6 may never see any value in = deploying it, so they never will. >=20 > It's not binary. You can represent as a number both the amount of pain = that a given problem (or set of problems) causes, and the amount of pain = that the big change in the network like adding a new protocol causes. >=20 > As soon as the first number is smaller than the second one, nothing = gets done. >=20 > Judging by the feedback I get from talking with people, even the = possibility of eventually eliminating RAs from their network might make = the second number smaller for a nontrivial amount folks, whose situation = dictates the DHCPv6. >=20 I find this very hard to believe. RAs are virtually automatic and free = in 99% of cases. If you feel the need to tune them, then that's pretty = trivial if you know enough to tune them properly. If you don't know what you are doing, then you can really mess yourself = up with RA tweaking that you shouldn't be doing. However, I do not advocate IETF breaking the internet just to prevent = people from breaking their LANs out of ignorance. >> There is no single answer to why people might resist deploying IPv6, = no single solution, and things that motivate people to deploy or not = IPv6 may have nothing to do with how IPv6 itself works. >>=20 >>=20 >>=20 >>> I think in this discussion are again getting into the argument of = "the best solution" instead of trying to collect the properties of the = RA and DHCP. >>> My position is that single best solution does not exist, because=20 >>=20 >>> everyone's problems are slightly different. So, rather than = preaching for everyone to adopt the single solution which is the best in = one scenario and suboptimal in the other, we should be engineering a way = to be able to apply different solutions in different circumstances = without the overhead of double work. >>=20 >> A single solution that solves most cases is better than two = different, >=20 > That's the point. The single solution that solves most cases, does not = exist. For a good part of the cases, you need to apply two solutions at = once. Justifiably, the question is "why", given in legacy IP they did = not need to do that. Actually, the problem is that people have conflated two different = problems and like to pretend that they are one. In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem. RAs solve the problem of telling a host which routers are available on = link. RAs also sort of solve the problem of dynamic host configuration = (address, RDNS servers, DNS Search list) For better or worse, to keep RAs very light weight, they do not provide = a complete or robust solution to host autoconfiguration. For that, you need DHCPv6 which is a protocol designed to do host = configuration. While I would like to see routing options added to DHCP for a variety of = reasons (mostly political and organizational rather than technical), I = do not for one second believe that eliminating RAs is useful in any = significant proportion of environments. Even if we made the changes you = are proposing, eliminating RAs would be unlikely in the vast majority of = circumstances, at least for many years to come. Owen From volz@cisco.com Sat Dec 7 18:55:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982051A1F08 for ; Sat, 7 Dec 2013 18:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abVJuTpufPHj for ; Sat, 7 Dec 2013 18:55:47 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1751A1F06 for ; Sat, 7 Dec 2013 18:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4631; q=dns/txt; s=iport; t=1386471343; x=1387680943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aqmoD05JNP+3rmsq938U47fCJSbd6OZOqCN29lre/gU=; b=VkRaT3Rg+vPfUxnw0UtVcOFDN76CluEJjJKrdkHxEARyQqLA1yObLC6a 2uk0r0RwJoijwtkTI/hvYYwUjJ8Sr/HocXNu2EA5GxjXkZseAI2ShXI45 sX8BSe8QCbB59sXgZvX7OkfZl6bXiz5DUqQ4XJR/5KWyEIjgFSen44wA4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAD/fo1KtJXHA/2dsb2JhbABZgwc4U7kTgRcWdIIlAQEBAwEBAQE3NAkCDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIE4dhBg2xZY40EwSOXzEHBoMagRMDqieBa4E+gio X-IronPort-AV: E=Sophos;i="4.93,849,1378857600"; d="scan'208";a="5146610" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-8.cisco.com with ESMTP; 08 Dec 2013 02:55:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB82tgaZ008813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Dec 2013 02:55:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sat, 7 Dec 2013 20:55:42 -0600 From: "Bernie Volz (volz)" To: Owen DeLong , "Andrew Yourtchenko (ayourtch)" Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO85Mt+o0A5U+FYEu6iB23uV31QJpJmk7A Date: Sun, 8 Dec 2013 02:55:41 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 02:55:49 -0000 >While I would like to see routing options added to DHCP for a variety of r= easons (mostly political and organizational rather than technical), I do no= t for one second believe that eliminating RAs is useful in any significant = proportion of environments. Yeah, I don't think they should go either. - Bernie -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Owen DeLong Sent: Saturday, December 07, 2013 4:23 PM To: Andrew Yourtchenko (ayourtch) Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcp= v6-comparison-00.txt (fwd) >> I don't think RAs are the single reason some people are resisting deploy= ing IPv6 at all. I think some people are resisting deploying IPv6 because i= t needs to do one or both of two things for them - solve a foreseeable prob= lem that will effect them, or provide a tangible benefit. If it won't do ei= ther of those things, then they don't currently see any value from the effo= rt involved. What are foreseeable problems or tangible benefits is complete= ly up to the perspective of the decision maker. Eventually they'll see valu= e in it, and deploy it. In some cases, some people who could deploy IPv6 ma= y never see any value in deploying it, so they never will. >=20 > It's not binary. You can represent as a number both the amount of pain th= at a given problem (or set of problems) causes, and the amount of pain that= the big change in the network like adding a new protocol causes. >=20 > As soon as the first number is smaller than the second one, nothing gets = done. >=20 > Judging by the feedback I get from talking with people, even the possibil= ity of eventually eliminating RAs from their network might make the second = number smaller for a nontrivial amount folks, whose situation dictates the = DHCPv6. >=20 I find this very hard to believe. RAs are virtually automatic and free in 9= 9% of cases. If you feel the need to tune them, then that's pretty trivial = if you know enough to tune them properly. If you don't know what you are doing, then you can really mess yourself up = with RA tweaking that you shouldn't be doing. However, I do not advocate IETF breaking the internet just to prevent peopl= e from breaking their LANs out of ignorance. >> There is no single answer to why people might resist deploying IPv6, no = single solution, and things that motivate people to deploy or not IPv6 may = have nothing to do with how IPv6 itself works. >>=20 >>=20 >>=20 >>> I think in this discussion are again getting into the argument of "the = best solution" instead of trying to collect the properties of the RA and DH= CP. >>> My position is that single best solution does not exist, because=20 >>=20 >>> everyone's problems are slightly different. So, rather than preaching f= or everyone to adopt the single solution which is the best in one scenario = and suboptimal in the other, we should be engineering a way to be able to a= pply different solutions in different circumstances without the overhead of= double work. >>=20 >> A single solution that solves most cases is better than two different, >=20 > That's the point. The single solution that solves most cases, does not ex= ist. For a good part of the cases, you need to apply two solutions at once.= Justifiably, the question is "why", given in legacy IP they did not need t= o do that. Actually, the problem is that people have conflated two different problems = and like to pretend that they are one. In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem. RAs solve the problem of telling a host which routers are available on link= . RAs also sort of solve the problem of dynamic host configuration (address, = RDNS servers, DNS Search list) For better or worse, to keep RAs very light weight, they do not provide a c= omplete or robust solution to host autoconfiguration. For that, you need DHCPv6 which is a protocol designed to do host configura= tion. While I would like to see routing options added to DHCP for a variety of re= asons (mostly political and organizational rather than technical), I do not= for one second believe that eliminating RAs is useful in any significant p= roportion of environments. Even if we made the changes you are proposing, e= liminating RAs would be unlikely in the vast majority of circumstances, at = least for many years to come. Owen _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From ayourtch@cisco.com Sat Dec 7 22:26:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D031ADBD2 for ; Sat, 7 Dec 2013 22:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eECu65NTyv_d for ; Sat, 7 Dec 2013 22:26:02 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 49D321ADBD0 for ; Sat, 7 Dec 2013 22:26:02 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB86PuxZ002289 for ; Sun, 8 Dec 2013 07:25:57 +0100 (CET) Received: from ams-ayourtch-8711.cisco.com (ams-ayourtch-8711.cisco.com [10.55.144.242]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB86Pr0v023417; Sun, 8 Dec 2013 07:25:54 +0100 (CET) Date: Sun, 8 Dec 2013 07:25:51 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Owen DeLong In-Reply-To: Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 06:26:05 -0000 On Sat, 7 Dec 2013, Owen DeLong wrote: >>> I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will. >> >> It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes, and the amount of pain that the big change in the network like adding a new protocol causes. >> >> As soon as the first number is smaller than the second one, nothing gets done. >> >> Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6. >> > > I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's pretty trivial if you know enough to tune them properly. > > If you don't know what you are doing, then you can really mess yourself up with RA tweaking that you shouldn't be doing. > > However, I do not advocate IETF breaking the internet just to prevent people from breaking their LANs out of ignorance. It's another protocol to run. It's not free. That the price varies for different parties is a different matter. > >>> There is no single answer to why people might resist deploying IPv6, no single solution, and things that motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works. >>> >>> >>> >>>> I think in this discussion are again getting into the argument of "the best solution" instead of trying to collect the properties of the RA and DHCP. >>>> My position is that single best solution does not exist, because >>> >>>> everyone's problems are slightly different. So, rather than preaching for everyone to adopt the single solution which is the best in one scenario and suboptimal in the other, we should be engineering a way to be able to apply different solutions in different circumstances without the overhead of double work. >>> >>> A single solution that solves most cases is better than two different, >> >> That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that. > > Actually, the problem is that people have conflated two different problems and like to pretend that they are one. > > In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem. > > RAs solve the problem of telling a host which routers are available on link. > RAs also sort of solve the problem of dynamic host configuration (address, RDNS servers, DNS Search list) > > For better or worse, to keep RAs very light weight, they do not provide a complete or robust solution to host autoconfiguration. > > For that, you need DHCPv6 which is a protocol designed to do host configuration. I think you nailed it here: With RA you *discover* the routers available on the link, with DHCP in legacy IP, you *configure* them. In some case you don't want the hosts to "discover" anything - your network does not change, you know your router, and actually having a way to *configure* it is more robust and secure than having to *discover* it. Why take away the tool from the toolbox ? Thanks for this, I think this is a very valuable point, I'll add it to the text - https://github.com/ayourtch/ra-dhcpv6/issues/9 > > While I would like to see routing options added to DHCP for a variety >of reasons (mostly political and organizational rather than technical), I >do not for one second believe that eliminating RAs is useful in any >significant proportion of environments. > Even if we made the changes you >are proposing, eliminating RAs would be unlikely in the vast majority of >circumstances, at least for many years to come. First off, I am not proposing to eliminate the RAs, at least not just yet. :-) I am proposing to stop blindly repeating "thou shall not eliminate RAs" mantra and explore with an open mind, what are the drivers behind people wanting to use DHCP-only, how hard would that be, and see on balance whether the juice is worth the squeeze. Second, there are no IPv6-only enterprise networks today, so eliminating RA would be *trivial* in those environments that want to eliminate them, as soon as 1-2 mainstream OSes were to support it. How ? Much the same as with DHCPv6-only networks today. Don't support the network's policy ? Fine, you are welcome to use your legacy IP stack until you do. And in any case "taking many years to come" is not an argument for not doing things. Case in point: IPv6 itself. --a > > Owen > > From owen@delong.com Sat Dec 7 22:42:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342551ADDBD for ; Sat, 7 Dec 2013 22:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts7wEv3lWGSx for ; Sat, 7 Dec 2013 22:42:28 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 63B681ADD9D for ; Sat, 7 Dec 2013 22:42:28 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB86g2Jo009004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Dec 2013 22:42:02 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB86g2Jo009004 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386484922; bh=tEi7HZy+DES1il18R/LUxk+zgBk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=UORGVt1QBFxgs0JJvrMqmvmTLIgpKB7sdeHu+2gW9dwCAsOuP8esetER2WbRG7MTJ TLR/Yb5t5gTURr9oGCrYcoyQwA9bpg+xwOWu3VwUysQF3k/t0qhsT/ktmi0aTamWAN rpMp+sXDuyaei8vmHPAJTI3cC1CyWCtFbYlQYSq8= Content-Type: multipart/alternative; boundary="Apple-Mail=_52263321-4114-4F2B-BA38-EF534F6F8B81" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: Date: Sat, 7 Dec 2013 22:40:37 -0800 Message-Id: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 07 Dec 2013 22:42:02 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 06:42:31 -0000 --Apple-Mail=_52263321-4114-4F2B-BA38-EF534F6F8B81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 7, 2013, at 22:25 , Andrew Yourtchenko = wrote: > On Sat, 7 Dec 2013, Owen DeLong wrote: >=20 >>>> I don't think RAs are the single reason some people are resisting = deploying IPv6 at all. I think some people are resisting deploying IPv6 = because it needs to do one or both of two things for them - solve a = foreseeable problem that will effect them, or provide a tangible = benefit. If it won't do either of those things, then they don't = currently see any value from the effort involved. What are foreseeable = problems or tangible benefits is completely up to the perspective of the = decision maker. Eventually they'll see value in it, and deploy it. In = some cases, some people who could deploy IPv6 may never see any value in = deploying it, so they never will. >>>=20 >>> It's not binary. You can represent as a number both the amount of = pain that a given problem (or set of problems) causes, and the amount of = pain that the big change in the network like adding a new protocol = causes. >>>=20 >>> As soon as the first number is smaller than the second one, nothing = gets done. >>>=20 >>> Judging by the feedback I get from talking with people, even the = possibility of eventually eliminating RAs from their network might make = the second number smaller for a nontrivial amount folks, whose situation = dictates the DHCPv6. >>>=20 >>=20 >> I find this very hard to believe. RAs are virtually automatic and = free in 99% of cases. If you feel the need to tune them, then that's = pretty trivial if you know enough to tune them properly. >>=20 >> If you don't know what you are doing, then you can really mess = yourself up with RA tweaking that you shouldn't be doing. >>=20 >> However, I do not advocate IETF breaking the internet just to prevent = people from breaking their LANs out of ignorance. >=20 > It's another protocol to run. It's not free. >=20 It seems free to me. I configure an address into my router and it starts = announcing RAs. > That the price varies for different parties is a different matter. Fair enough, but it's free or very nearly free for the vast majority of = parties. >>>> There is no single answer to why people might resist deploying = IPv6, no single solution, and things that motivate people to deploy or = not IPv6 may have nothing to do with how IPv6 itself works. >>>>=20 >>>>=20 >>>>=20 >>>>> I think in this discussion are again getting into the argument of = "the best solution" instead of trying to collect the properties of the = RA and DHCP. >>>>> My position is that single best solution does not exist, because >>>>=20 >>>>> everyone's problems are slightly different. So, rather than = preaching for everyone to adopt the single solution which is the best in = one scenario and suboptimal in the other, we should be engineering a way = to be able to apply different solutions in different circumstances = without the overhead of double work. >>>>=20 >>>> A single solution that solves most cases is better than two = different, >>>=20 >>> That's the point. The single solution that solves most cases, does = not exist. For a good part of the cases, you need to apply two solutions = at once. Justifiably, the question is "why", given in legacy IP they did = not need to do that. >>=20 >> Actually, the problem is that people have conflated two different = problems and like to pretend that they are one. >>=20 >> In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem. >>=20 >> RAs solve the problem of telling a host which routers are available = on link. >> RAs also sort of solve the problem of dynamic host configuration = (address, RDNS servers, DNS Search list) >>=20 >> For better or worse, to keep RAs very light weight, they do not = provide a complete or robust solution to host autoconfiguration. >>=20 >> For that, you need DHCPv6 which is a protocol designed to do host = configuration. >=20 > I think you nailed it here: With RA you *discover* the routers = available on the link, with DHCP in legacy IP, you *configure* them. No, with DHCP, you discovered what some remote host rumored them to be. > In some case you don't want the hosts to "discover" anything - your = network does not change, you know your router, and actually having a way = to *configure* it is more robust and secure than having to *discover* = it. Why take away the tool from the toolbox ? Your host is always discovering things. IP doesn't work without = discovery (at least not in any practical way for the vast majority of = applications). In IPv4, ARP is used to discover the MAC address of = adjacent hosts, for example. In IPv6, we use Neighbor Solicitation and = Neighbor Advertisement to do roughly the same thing. There are a number of advantages to finding out what routers are = available to you FROM THE ROUTERS instead of getting rumors from some = remote server which may or may not be accurate in general and certainly = have a reasonable chance of being flat out wrong in the event of any = failure condition. A network that doesn't change is an amusing fallacy. I will agree that = there are some networks which don't change until they do. However, I = have yet to see a network that didn't change. > Thanks for this, I think this is a very valuable point, I'll add it to = the text - https://github.com/ayourtch/ra-dhcpv6/issues/9 If you do so, please do not misconstrue my remarks the way you have in = this case. >=20 >>=20 >> While I would like to see routing options added to DHCP for a variety = of reasons (mostly political and organizational rather than technical), = I do not for one second believe that eliminating RAs is useful in any = significant proportion of environments. >> Even if we made the changes you are proposing, eliminating RAs would = be unlikely in the vast majority of circumstances, at least for many = years to come. >=20 >=20 > First off, I am not proposing to eliminate the RAs, at least not just = yet. :-) >=20 I didn't mean eliminating them in general. I meant that I am very hard = pressed to imagine any scenario where a network would benefit from = eliminating them other than certain environments that would probably be = better suited to 6LOWPAN anyway. > I am proposing to stop blindly repeating "thou shall not eliminate = RAs" mantra and explore with an open mind, what are the drivers behind = people wanting to use DHCP-only, how hard would that be, and see on = balance whether the juice is worth the squeeze. I've been through that exercise. I'm all for giving DHCP the ability to = provide routing information. I've said as much on numerous occasions. However, even on a network that is running "DHCP only" you gain nothing = (at least in the vast majority of circumstances) and lose significant = robustness if you turn off RAs. > Second, there are no IPv6-only enterprise networks today, so = eliminating RA would be *trivial* in those environments that want to = eliminate them, as soon as 1-2 mainstream OSes were to support it. That isn't true. I doubt seriously that there are no IPv6-only = enterprise networks, but I accept that there are very few. However, eliminating RA in those environments that want to eliminate = them would not be trivial. You'd have to upgrade every desktop OS and = every other dynamically configured device because in the current running = code, DHCP doesn't work without an RA to tell it "go ask the DHCP = server". > How ? Much the same as with DHCPv6-only networks today. Don't support = the network's policy ? Fine, you are welcome to use your legacy IP stack = until you do. There are no DHCPv6-only networks today. > And in any case "taking many years to come" is not an argument for not = doing things. It is an argument against putting significant risk into a deployed = codebase for a minuscule gain for a very small number of beneficiaries. > Case in point: IPv6 itself. IPv6 itself didn't involve deploying incompatible updates that will = potentially interfere with a deployed operational protocol. The changes = you are proposing (to make hosts do DHCP without bootstrapping it = through the RA process) are different. Those are not at all unlikely to = be problematic in a number of difficult to predict ways. Personally, I would much rather see us focus on the following easily = achievable goals that I think matter to a lot more people: 1. Provide more consistent guidance on the interactions of = M, O, and A flags in RAs and how RAs should be processed. 2. Provide more consistent guidance on the interactions of = RAs that disagree. While this is arguably a "broken network" condition, it is a form of brokenness where having a = defined and deterministic mode of failure is more desirable than the current "depends on the host OS, phase of the moon, = and 2d20 roll of the operator" scenario. 3. Add routing information to DHCP for those that want to = use it. Owen --Apple-Mail=_52263321-4114-4F2B-BA38-EF534F6F8B81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Dec 7, 2013, at 22:25 , Andrew = Yourtchenko <ayourtch@cisco.com> = wrote:

On Sat, 7 Dec 2013, Owen DeLong = wrote:

I don't think RAs are the single = reason some people are resisting deploying IPv6 at all. I think some = people are resisting deploying IPv6 because it needs to do one or both = of two things for them - solve a foreseeable problem that will effect = them, or provide a tangible benefit. If it won't do either of those = things, then they don't currently see any value from the effort = involved. What are foreseeable problems or tangible benefits is = completely up to the perspective of the decision maker. Eventually = they'll see value in it, and deploy it. In some cases, some people who = could deploy IPv6 may never see any value in deploying it, so they never = will.

It's not binary. You can represent as a number = both the amount of pain that a given problem (or set of problems) = causes, and the amount of pain that the big change in the network like = adding a new protocol causes.

As soon as the first number is = smaller than the second one, nothing gets done.

Judging by the = feedback I get from talking with people, even the possibility of = eventually eliminating RAs from their network might make the second = number smaller for a nontrivial amount folks, whose situation dictates = the DHCPv6.


I find this very hard to believe. = RAs are virtually automatic and free in 99% of cases. If you feel the = need to tune them, then that's pretty trivial if you know enough to tune = them properly.

If you don't know what you are doing, then you can = really mess yourself up with RA tweaking that you shouldn't be = doing.

However, I do not advocate IETF breaking the internet just = to prevent people from breaking their LANs out of = ignorance.

It's another protocol to run. It's not = free.


It seems free to me. I = configure an address into my router and it starts announcing = RAs.

That the price = varies for different parties is a different = matter.

Fair enough, but it's free = or very nearly free for the vast majority of = parties.

There = is no single answer to why people might resist deploying IPv6, no single = solution, and things that motivate people to deploy or not IPv6 may have = nothing to do with how IPv6 itself works.



I think in this discussion are again getting into the = argument of "the best solution" instead of trying to collect the = properties of the RA and DHCP.
My position is that single best = solution does not exist, because

everyone's problems are slightly different. So, rather = than preaching for everyone to adopt the single solution which is the = best in one scenario and suboptimal in the other, we should be = engineering a way to be able to apply different solutions in different = circumstances without the overhead of double work.

A = single solution that solves most cases is better than two = different,

That's the point. The single solution = that solves most cases, does not exist. For a good part of the cases, = you need to apply two solutions at once. Justifiably, the question is = "why", given in legacy IP they did not need to do = that.

Actually, the problem is that people have = conflated two different problems and like to pretend that they are = one.

In fact, RAs solve 1.5 problems and DHCPv6 solves 1 = problem.

RAs solve the problem of telling a host which routers = are available on link.
RAs also sort of solve the problem of dynamic = host configuration (address, RDNS servers, DNS Search list)

For = better or worse, to keep RAs very light weight, they do not provide a = complete or robust solution to host autoconfiguration.

For that, = you need DHCPv6 which is a protocol designed to do host = configuration.

I think you nailed it here: With RA = you *discover* the routers available on the link, with DHCP in legacy = IP, you *configure* them.

No, = with DHCP, you discovered what some remote host rumored them to = be.

In = some case you don't want the hosts to "discover" anything - your network = does not change, you know your router, and actually having a way to = *configure* it is more robust and secure than having to *discover* it. = Why take away the tool from the toolbox = ?

Your host is always = discovering things. IP doesn't work without discovery (at least not in = any practical way for the vast majority of applications). In IPv4, ARP = is used to discover the MAC address of adjacent hosts, for example. In = IPv6, we use Neighbor Solicitation and Neighbor Advertisement to do = roughly the same thing.

There are a number of = advantages to finding out what routers are available to you FROM THE = ROUTERS instead of getting rumors from some remote server which may or = may not be accurate in general and certainly have a reasonable chance of = being flat out wrong in the event of any failure = condition.

A network that doesn't change is an = amusing fallacy. I will agree that there are some networks which don't = change until they do. However, I have yet to see a network that didn't = change.

Thanks = for this, I think this is a very valuable point, I'll add it to the text = - https://github.com= /ayourtch/ra-dhcpv6/issues/9

If = you do so, please do not misconstrue my remarks the way you have in this = case.



While I would like to see = routing options added to DHCP for a variety of reasons (mostly political = and organizational rather than technical), I do not for one second = believe that eliminating RAs is useful in any significant proportion of = environments.
Even if we made the changes you are proposing, = eliminating RAs would be unlikely in the vast majority of circumstances, = at least for many years to come.


First off, I am = not proposing to eliminate the RAs, at least not just yet. = :-)


I didn't mean eliminating = them in general. I meant that I am very hard pressed to imagine any = scenario where a network would benefit from eliminating them other than = certain environments that would probably be better suited to 6LOWPAN = anyway.

I am proposing = to stop blindly repeating "thou shall not eliminate RAs" mantra and = explore with an open mind, what are the drivers behind people wanting to = use DHCP-only, how hard would that be, and see on balance whether the = juice is worth the squeeze.

I've = been through that exercise. I'm all for giving DHCP the ability to = provide routing information. I've said as much on numerous = occasions.

However, even on a network that is = running "DHCP only" you gain nothing (at least in the vast majority of = circumstances) and lose significant robustness if you turn off = RAs.

Second, there = are no IPv6-only enterprise networks today, so eliminating RA would be = *trivial* in those environments that want to eliminate them, as soon as = 1-2 mainstream OSes were to support = it.

That isn't true. I doubt = seriously that there are no IPv6-only enterprise networks, but I accept = that there are very few.

However, eliminating = RA in those environments that want to eliminate them would not be = trivial. You'd have to upgrade every desktop OS and every other = dynamically configured device because in the current running code, DHCP = doesn't work without an RA to tell it "go ask the DHCP = server".

How ? Much the = same as with DHCPv6-only networks today. Don't support the network's = policy ? Fine, you are welcome to use your legacy IP stack until you = do.

There are no DHCPv6-only = networks today.

And in = any case "taking many years to come" is not an argument for not doing = things.

It is an argument against = putting significant risk into a deployed codebase for a minuscule gain = for a very small number of beneficiaries.

Case in point: IPv6 = itself.

IPv6 itself didn't involve = deploying incompatible updates that will potentially interfere with a = deployed operational protocol. The changes you are proposing (to make = hosts do DHCP without bootstrapping it through the RA process) are = different. Those are not at all unlikely to be problematic in a number = of difficult to predict ways.

Personally, I = would much rather see us focus on the following easily achievable goals = that I think matter to a lot more people:

1. Provide = more consistent guidance on the interactions of M, O, and A flags in RAs = and how RAs should be processed.
2. Provide more consistent guidance = on the interactions of RAs that disagree. While this is arguably a = "broken network"
condition, it is a form = of brokenness where having a defined and deterministic mode of failure = is more desirable than
the current "depends on = the host OS, phase of the moon, and 2d20 roll of the operator" = scenario.
3. Add routing information to DHCP = for those that want to use = it.

Owen

= --Apple-Mail=_52263321-4114-4F2B-BA38-EF534F6F8B81-- From ayourtch@cisco.com Sat Dec 7 22:44:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81A21ADDBD for ; Sat, 7 Dec 2013 22:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOV6uRSuVp6g for ; Sat, 7 Dec 2013 22:44:32 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 44DBF1ADD9D for ; Sat, 7 Dec 2013 22:44:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB86iRgb003929 for ; Sun, 8 Dec 2013 07:44:27 +0100 (CET) Received: from ams-ayourtch-8711.cisco.com (ams-ayourtch-8711.cisco.com [10.55.144.242]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB86iN8u029629; Sun, 8 Dec 2013 07:44:23 +0100 (CET) Date: Sun, 8 Dec 2013 07:44:21 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "Bernie Volz (volz)" In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 06:44:35 -0000 On Sun, 8 Dec 2013, Bernie Volz (volz) wrote: >> While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments. > > Yeah, I don't think they should go either. Again, I am *not* proposing to deprecate them. I'm proposing to decriminalize the thinking of allowing to not use them. --a > > - Bernie > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Owen DeLong > Sent: Saturday, December 07, 2013 4:23 PM > To: Andrew Yourtchenko (ayourtch) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) > >>> I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will. >> >> It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes, and the amount of pain that the big change in the network like adding a new protocol causes. >> >> As soon as the first number is smaller than the second one, nothing gets done. >> >> Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6. >> > > I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's pretty trivial if you know enough to tune them properly. > > If you don't know what you are doing, then you can really mess yourself up with RA tweaking that you shouldn't be doing. > > However, I do not advocate IETF breaking the internet just to prevent people from breaking their LANs out of ignorance. > >>> There is no single answer to why people might resist deploying IPv6, no single solution, and things that motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works. >>> >>> >>> >>>> I think in this discussion are again getting into the argument of "the best solution" instead of trying to collect the properties of the RA and DHCP. >>>> My position is that single best solution does not exist, because >>> >>>> everyone's problems are slightly different. So, rather than preaching for everyone to adopt the single solution which is the best in one scenario and suboptimal in the other, we should be engineering a way to be able to apply different solutions in different circumstances without the overhead of double work. >>> >>> A single solution that solves most cases is better than two different, >> >> That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that. > > Actually, the problem is that people have conflated two different problems and like to pretend that they are one. > > In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem. > > RAs solve the problem of telling a host which routers are available on link. > RAs also sort of solve the problem of dynamic host configuration (address, RDNS servers, DNS Search list) > > For better or worse, to keep RAs very light weight, they do not provide a complete or robust solution to host autoconfiguration. > For that, you need DHCPv6 which is a protocol designed to do host configuration. > > While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments. Even if we made the changes you are proposing, eliminating RAs would be unlikely in the vast majority of circumstances, at least for many years to come. > > Owen > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ayourtch@cisco.com Sun Dec 8 00:35:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEB1ADF43 for ; Sun, 8 Dec 2013 00:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkC0tT_e5BTO for ; Sun, 8 Dec 2013 00:35:07 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B5A351ADE84 for ; Sun, 8 Dec 2013 00:35:06 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB88Z0vO013567 for ; Sun, 8 Dec 2013 09:35:00 +0100 (CET) Received: from ams-ayourtch-8711.cisco.com (ams-ayourtch-8711.cisco.com [10.55.144.242]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB88YunD008500; Sun, 8 Dec 2013 09:34:56 +0100 (CET) Date: Sun, 8 Dec 2013 09:34:51 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Owen DeLong In-Reply-To: Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-70768129-1386491693=:68814" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 08:35:10 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-70768129-1386491693=:68814 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 7 Dec 2013, Owen DeLong wrote: > > On Dec 7, 2013, at 22:25 , Andrew Yourtchenko wrote: > > On Sat, 7 Dec 2013, Owen DeLong wrote: > > I don't think RAs are the single reason some people are resisting deploying IPv6 at all. I think some people > are resisting deploying IPv6 because it needs to do one or both of two things for them - solve a foreseeable > problem that will effect them, or provide a tangible benefit. If it won't do either of those things, then they > don't currently see any value from the effort involved. What are foreseeable problems or tangible benefits is > completely up to the perspective of the decision maker. Eventually they'll see value in it, and deploy it. In > some cases, some people who could deploy IPv6 may never see any value in deploying it, so they never will. > > > It's not binary. You can represent as a number both the amount of pain that a given problem (or set of problems) causes, > and the amount of pain that the big change in the network like adding a new protocol causes. > > As soon as the first number is smaller than the second one, nothing gets done. > > Judging by the feedback I get from talking with people, even the possibility of eventually eliminating RAs from their > network might make the second number smaller for a nontrivial amount folks, whose situation dictates the DHCPv6. > > > I find this very hard to believe. RAs are virtually automatic and free in 99% of cases. If you feel the need to tune them, then that's > pretty trivial if you know enough to tune them properly. > > If you don't know what you are doing, then you can really mess yourself up with RA tweaking that you shouldn't be doing. > > However, I do not advocate IETF breaking the internet just to prevent people from breaking their LANs out of ignorance. > > > It's another protocol to run. It's not free. > > > It seems free to me. I configure an address into my router and it starts announcing RAs. > That's the crux. It's free to you, so you make the leap "so it's free". > That the price varies for different parties is a different matter. > > > Fair enough, but it's free or very nearly free for the vast majority of parties. You need to take care: 1) that the RAs from the router reach the hosts. 2) that only the RAs from *your* router reach the hosts. either of the two may be a non-issue for *you* but the induction that it's a non-issue for *everyone* is incorrect. > > There is no single answer to why people might resist deploying IPv6, no single solution, and things that > motivate people to deploy or not IPv6 may have nothing to do with how IPv6 itself works. > > > > I think in this discussion are again getting into the argument of "the best solution" instead of > trying to collect the properties of the RA and DHCP. > My position is that single best solution does not exist, because > > > everyone's problems are slightly different. So, rather than preaching for everyone to adopt the > single solution which is the best in one scenario and suboptimal in the other, we should be > engineering a way to be able to apply different solutions in different circumstances without the > overhead of double work. > > > A single solution that solves most cases is better than two different, > > > That's the point. The single solution that solves most cases, does not exist. For a good part of the cases, you need to > apply two solutions at once. Justifiably, the question is "why", given in legacy IP they did not need to do that. > > > Actually, the problem is that people have conflated two different problems and like to pretend that they are one. > > In fact, RAs solve 1.5 problems and DHCPv6 solves 1 problem. > > RAs solve the problem of telling a host which routers are available on link. > RAs also sort of solve the problem of dynamic host configuration (address, RDNS servers, DNS Search list) > > For better or worse, to keep RAs very light weight, they do not provide a complete or robust solution to host autoconfiguration. > > For that, you need DHCPv6 which is a protocol designed to do host configuration. > > > I think you nailed it here: With RA you *discover* the routers available on the link, with DHCP in legacy IP, you *configure* them. > > > No, with DHCP, you discovered what some remote host rumored them to be. > > In some case you don't want the hosts to "discover" anything - your network does not change, you know your router, and actually having a way to > *configure* it is more robust and secure than having to *discover* it. Why take away the tool from the toolbox ? > > > Your host is always discovering things. IP doesn't work without discovery (at least not in any practical way for the vast majority of applications). In IPv4, > ARP is used to discover the MAC address of adjacent hosts, for example. In IPv6, we use Neighbor Solicitation and Neighbor Advertisement to do roughly the same > thing. > > There are a number of advantages to finding out what routers are available to you FROM THE ROUTERS instead of getting rumors from some remote server which may > or may not be accurate in general and certainly have a reasonable chance of being flat out wrong in the event of any failure condition. > > A network that doesn't change is an amusing fallacy. I will agree that there are some networks which don't change until they do. However, I have yet to see a > network that didn't change. There are a number of advantages to NOT finding out from the routers that they are the routers in an unauthenticated manner. The environments vary. > > Thanks for this, I think this is a very valuable point, I'll add it to the text - https://github.com/ayourtch/ra-dhcpv6/issues/9 > > > If you do so, please do not misconstrue my remarks the way you have in this case. > Okay, I will not add you to the "acknowledgements", and will treat that idea as my own, FWIW. > > > While I would like to see routing options added to DHCP for a variety of reasons (mostly political and organizational rather than > technical), I do not for one second believe that eliminating RAs is useful in any significant proportion of environments. > Even if we made the changes you are proposing, eliminating RAs would be unlikely in the vast majority of circumstances, at least for > many years to come. > > > > First off, I am not proposing to eliminate the RAs, at least not just yet. :-) > > > I didn't mean eliminating them in general. I meant that I am very hard pressed to imagine any scenario where a network would benefit from eliminating them > other than certain environments that would probably be better suited to 6LOWPAN anyway. Did you read the draft mentioned in the subject line ? > > I am proposing to stop blindly repeating "thou shall not eliminate RAs" mantra and explore with an open mind, what are the drivers behind people > wanting to use DHCP-only, how hard would that be, and see on balance whether the juice is worth the squeeze. > > > I've been through that exercise. I'm all for giving DHCP the ability to provide routing information. I've said as much on numerous occasions. > > However, even on a network that is running "DHCP only" you gain nothing (at least in the vast majority of circumstances) and lose significant robustness if you > turn off RAs. Legacy IP runs fine with no RAs. Quite robustly. > > Second, there are no IPv6-only enterprise networks today, so eliminating RA would be *trivial* in those environments that want to eliminate them, > as soon as 1-2 mainstream OSes were to support it. > > > That isn't true. I doubt seriously that there are no IPv6-only enterprise networks, but I accept that there are very few. > > However, eliminating RA in those environments that want to eliminate them would not be trivial. You'd have to upgrade every desktop OS and every other > dynamically configured device because in the current running code, DHCP doesn't work without an RA to tell it "go ask the DHCP server". My OS upgrades itself every other week. And installs apps, bugfixes, and such. Autoupdate exists and works. In a stricter environment you have an IT department building the golden setups. The image lifecycle there is 3-5 years. > > How ? Much the same as with DHCPv6-only networks today. Don't support the network's policy ? Fine, you are welcome to use your legacy IP stack > until you do. > > > There are no DHCPv6-only networks today. I was using one just on Friday. > > And in any case "taking many years to come" is not an argument for not doing things. > > > It is an argument against putting significant risk into a deployed codebase for a minuscule gain for a very small number of beneficiaries. > > Case in point: IPv6 itself. > > > IPv6 itself didn't involve deploying incompatible updates that will potentially interfere with a deployed operational protocol. IPv6 is completely incompatible with the deployed operational IPv4, and in the rfc3484 case a broken IPv6 completely screws up your perfectly working IPv4. > The changes you are proposing > (to make hosts do DHCP without bootstrapping it through the RA process) >are different. Those are not at all unlikely to be problematic in a >number of difficult > to predict ways. Again, all I am proposing is to decriminalize the thinking about proposing DHCPv6-only operation and its implications, and be able to write it up for further balanced analysis. If you have an opinion that is a useless activity - absolutely fine. I registered that. Let's move on and if you do not have any comments on the text itself, we can wrap this sub-thread up. > > Personally, I would much rather see us focus on the following easily achievable goals that I think matter to a lot more people: > > 1. Provide more consistent guidance on the interactions of M, O, and A flags in RAs and how RAs should be processed. This is great - (though, if we were to use the argument you used previously - why bother ? it will anyway take forever to achieve the consistency). Documenting the existing behavior is a great start, anyway. draft-ietf-v6ops-dhcpv6-slaac-problem is awesome. > 2. Provide more consistent guidance on the interactions of RAs that disagree. While this is arguably a "broken network" > condition, it is a form of brokenness where having a defined and deterministic mode of failure is more desirable than > the current "depends on the host OS, phase of the moon, and 2d20 roll of the operator" scenario. This is indeed a broken network. Use router priorities - it's an existing and deployed mechanism which trivially resolves the conflicts with no ambiguity and no code changes required. (Of course, assuming the host implements them and implements correctly). > 3. Add routing information to DHCP for those that want to use it. It will end up in the threads exactly like this one, just with different people. --a --0-70768129-1386491693=:68814-- From brian.e.carpenter@gmail.com Sun Dec 8 11:22:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878641AE08C for ; Sun, 8 Dec 2013 11:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8Y7NzwvieXb for ; Sun, 8 Dec 2013 11:22:47 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 218C11AE08B for ; Sun, 8 Dec 2013 11:22:47 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so3889769pdj.12 for ; Sun, 08 Dec 2013 11:22:42 -0800 (PST) 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=5WXsnQTiY4EIQ3S4LgH8qGBnyCm3xW1Ck3L9CLuBZRU=; b=d+iO36Mqql4TVCYf7h4t8Z7itXb88+aDVpk6FU3+ijoR+AHDD9wmG8urdIfCWh0RdB WmdhiUBRSPhBl15DQUpt/H2Ld0e4hb4xs0DuO5bD2vcBhf2cNom75OMHu1PDBpuecbFp uF6LuiAizypb6OV2FgxV/6y6dLRNfmhTsI+VQKI7bHn0xHJOgMug2qbY/YHiM9swJf4o x8kkHcvlj3WL3pn9ZP8snc4iUBObpFFy6r0CQLKNYyV3MmCScJNske66PglMgd54PpcA epYKfeMTD+8Sqpu/odS8SSIFkBPw7Z6f2fi8q6bX+NS/cakYg1SXMt3BEdpZYCqQUtLZ /7jA== X-Received: by 10.68.59.202 with SMTP id b10mr16780630pbr.78.1386530560679; Sun, 08 Dec 2013 11:22:40 -0800 (PST) Received: from [192.168.178.20] (27.198.69.111.dynamic.snap.net.nz. [111.69.198.27]) by mx.google.com with ESMTPSA id sd3sm12595666pbb.42.2013.12.08.11.22.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Dec 2013 11:22:40 -0800 (PST) Message-ID: <52A4C6FD.1080504@gmail.com> Date: Mon, 09 Dec 2013 08:22:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 19:22:48 -0000 On 08/12/2013 19:40, Owen DeLong wrote: > On Dec 7, 2013, at 22:25 , Andrew Yourtchenko wrote: ... >> I think you nailed it here: With RA you *discover* the routers available on the link, with DHCP in legacy IP, you *configure* them. > > No, with DHCP, you discovered what some remote host rumored them to be. I don't think we should be having this argument. We should be trying to write down objectively the type of scenarios where DHCPv6 is applicable, the type of scenarios where RA-only is applicable, and the type of scenarios where both (simultaneously) are applicable. There's no right or wrong answer here. Brian From owen@delong.com Sun Dec 8 11:38:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43571AE09F for ; Sun, 8 Dec 2013 11:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lW7fq7i9oaU for ; Sun, 8 Dec 2013 11:38:01 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AA8311AE05F for ; Sun, 8 Dec 2013 11:38:01 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB8Jb8t3014390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Dec 2013 11:37:08 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB8Jb8t3014390 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386531428; bh=kuGRKHLmck9tIMmcMTLhAVXnLec=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=dE+ol+LHxkcLJLJXApismi8NqYzg0aDWi1uVXHzapfH2trdXTGDxbLB15YsTTrtKx xUxspYoAXY6lBqLIjgxJsICMPWL6JRJilofjci36o2PEhY9CLD4LKa/l134qcmpMVZ 7EOrR+0N9at9v3KzWIv7ZD6GOQkoKm7IdWC9bFNQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_1F986388-D833-4051-A4EA-E0C6EF326683" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: Date: Sun, 8 Dec 2013 11:35:20 -0800 Message-Id: <4B010A17-158D-455E-B4BA-C3457C4BE9CC@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 08 Dec 2013 11:37:08 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 19:38:06 -0000 --Apple-Mail=_1F986388-D833-4051-A4EA-E0C6EF326683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> That the price varies for different parties is a different = matter. >> Fair enough, but it's free or very nearly free for the vast majority = of parties. >=20 > You need to take care: >=20 > 1) that the RAs from the router reach the hosts. If they don't, you have a broken network and your other packets likely = aren't reaching those hosts, either. Beyond that, that's why things get = retried. At least in the case of RAs, they only have to travel a single hop. DHCP = is often much more remote. At its best, DHCP cannot be any better than = in this regard. > 2) that only the RAs from *your* router reach the hosts. This is no different from the rogue DHCP server problem, so I am again, = not impressed. An RA attacker has to be on-link. If you have hostile = hosts on-link in your LAN, then you have bigger problems than rogue RA = in most cases. > either of the two may be a non-issue for *you* but the induction that = it's a non-issue for *everyone* is incorrect. It's not a non-issue, but DHCP has the same problems. >=20 >>=20 >> There is no single answer to why people might = resist deploying IPv6, no single solution, and things that >> motivate people to deploy or not IPv6 may have = nothing to do with how IPv6 itself works. >>=20 >> I think in this discussion are again = getting into the argument of "the best solution" instead of >> trying to collect the properties of the = RA and DHCP. >> My position is that single best solution = does not exist, because >>=20 >> everyone's problems are slightly = different. So, rather than preaching for everyone to adopt the >> single solution which is the best in one = scenario and suboptimal in the other, we should be >> engineering a way to be able to apply = different solutions in different circumstances without the >> overhead of double work. >>=20 >> A single solution that solves most cases is = better than two different, >>=20 >> That's the point. The single solution that solves = most cases, does not exist. For a good part of the cases, you need to >> apply two solutions at once. Justifiably, the = question is "why", given in legacy IP they did not need to do that. >>=20 >> Actually, the problem is that people have conflated two = different problems and like to pretend that they are one. >>=20 >> In fact, RAs solve 1.5 problems and DHCPv6 solves 1 = problem. >>=20 >> RAs solve the problem of telling a host which routers are = available on link. >> RAs also sort of solve the problem of dynamic host = configuration (address, RDNS servers, DNS Search list) >>=20 >> For better or worse, to keep RAs very light weight, they = do not provide a complete or robust solution to host autoconfiguration. >>=20 >> For that, you need DHCPv6 which is a protocol designed to = do host configuration. >>=20 >> I think you nailed it here: With RA you *discover* the routers = available on the link, with DHCP in legacy IP, you *configure* them. >> No, with DHCP, you discovered what some remote host rumored them to = be. >>=20 >> In some case you don't want the hosts to "discover" anything - = your network does not change, you know your router, and actually having = a way to >> *configure* it is more robust and secure than having to = *discover* it. Why take away the tool from the toolbox ? >> Your host is always discovering things. IP doesn't work without = discovery (at least not in any practical way for the vast majority of = applications). In IPv4, >> ARP is used to discover the MAC address of adjacent hosts, for = example. In IPv6, we use Neighbor Solicitation and Neighbor = Advertisement to do roughly the same >> thing. >> There are a number of advantages to finding out what routers are = available to you FROM THE ROUTERS instead of getting rumors from some = remote server which may >> or may not be accurate in general and certainly have a reasonable = chance of being flat out wrong in the event of any failure condition. >> A network that doesn't change is an amusing fallacy. I will agree = that there are some networks which don't change until they do. However, = I have yet to see a >> network that didn't change. >=20 > There are a number of advantages to NOT finding out from the routers = that they are the routers in an unauthenticated manner. Then use SEND or turn of RA on your routers and deal with the = consequences of having to statically configure routes on every host = and/or run a routing protocol on every host. I don't see any advantage to a route from an unauthenticated DHCP server = over a route from an unauthenticated router. > The environments vary. Sure, but the basic principles involved do not. >> Thanks for this, I think this is a very valuable point, I'll add = it to the text - https://github.com/ayourtch/ra-dhcpv6/issues/9 >> If you do so, please do not misconstrue my remarks the way you have = in this case. >>=20 >=20 > Okay, I will not add you to the "acknowledgements", and will treat = that idea as my own, FWIW. So you think it is better to misquote me out of context without = attribution than to simply not misquote me out of context? Somehow I = don't really see that as an improvement. >> While I would like to see routing options added to DHCP = for a variety of reasons (mostly political and organizational rather = than >> technical), I do not for one second believe that = eliminating RAs is useful in any significant proportion of environments. >> Even if we made the changes you are proposing, eliminating = RAs would be unlikely in the vast majority of circumstances, at least = for >> many years to come. >>=20 >> First off, I am not proposing to eliminate the RAs, at least not = just yet. :-) >> I didn't mean eliminating them in general. I meant that I am very = hard pressed to imagine any scenario where a network would benefit from = eliminating them >> other than certain environments that would probably be better suited = to 6LOWPAN anyway. >=20 > Did you read the draft mentioned in the subject line ? Yes, but I did not find it compelling. >> I am proposing to stop blindly repeating "thou shall not = eliminate RAs" mantra and explore with an open mind, what are the = drivers behind people >> wanting to use DHCP-only, how hard would that be, and see on = balance whether the juice is worth the squeeze. >> I've been through that exercise. I'm all for giving DHCP the ability = to provide routing information. I've said as much on numerous occasions. >> However, even on a network that is running "DHCP only" you gain = nothing (at least in the vast majority of circumstances) and lose = significant robustness if you >> turn off RAs. >=20 > Legacy IP runs fine with no RAs. Quite robustly. Legacy IP has numerous problems, actually. We've gotten used to coping = with them. The fact that we have come to accept chronic pain is not a = valid reason to avoid seeking proper medical treatment. Indeed, most of = the problems you claim are specific to RA have variants that apply = equally strongly to DHCP in both IPv6 and in Legacy IP. >> Second, there are no IPv6-only enterprise networks today, so = eliminating RA would be *trivial* in those environments that want to = eliminate them, >> as soon as 1-2 mainstream OSes were to support it. >> That isn't true. I doubt seriously that there are no IPv6-only = enterprise networks, but I accept that there are very few. >> However, eliminating RA in those environments that want to eliminate = them would not be trivial. You'd have to upgrade every desktop OS and = every other >> dynamically configured device because in the current running code, = DHCP doesn't work without an RA to tell it "go ask the DHCP server". >=20 > My OS upgrades itself every other week. And installs apps, bugfixes, = and such. Autoupdate exists and works. In a stricter environment you = have an IT department building the golden setups. The image lifecycle = there is 3-5 > years. I'm happy for you, but that's not the case for the vast majority of = enterprises where Windows "autoupdate" is not so well trusted. Talk to any IT department in any organization of substantial size and = ask them if they have complete 100% control over the update cycle of = absolutely every machine on the network. I'm willing to bet that not one = of them can honestly answer that question in the affirmative. There's = always some piece of software that someone deems critical to the = enterprise at a high enough level which can't be updated for some = reason. The longer an enterprise is in business and the larger it = becomes, the more of these exceptional cases emerge. >> How ? Much the same as with DHCPv6-only networks today. Don't = support the network's policy ? Fine, you are welcome to use your legacy = IP stack >> until you do. >> There are no DHCPv6-only networks today. >=20 > I was using one just on Friday. How did you get the clients to ask the DHCP server for something without = giving it an M|O Bit RA? Arguably, said clients are not behaving according to the RFCs. >> And in any case "taking many years to come" is not an argument = for not doing things. >> It is an argument against putting significant risk into a deployed = codebase for a minuscule gain for a very small number of beneficiaries. >>=20 >> Case in point: IPv6 itself. >> IPv6 itself didn't involve deploying incompatible updates that will = potentially interfere with a deployed operational protocol. >=20 > IPv6 is completely incompatible with the deployed operational IPv4, = and in the rfc3484 case a broken IPv6 completely screws up your = perfectly working IPv4. No, IPv6 is a completely separate protocol. Yes, there are certain ways = to break name resolution for IPv4 with IPv6 misconfiguration, but that = is because of the shared name service. IPv6 the protocol does _NOT_ = interfere with IPv4 the protocol on the wire. The issues in RFC3484 are = entirely related to DNS being shared between the two protocols. >> The changes you are proposing >> (to make hosts do DHCP without bootstrapping it through the RA = process) are different. Those are not at all unlikely to be problematic = in a number of difficult >> to predict ways. >=20 > Again, all I am proposing is to decriminalize the thinking about = proposing DHCPv6-only operation and its implications, and be able to = write it up for further balanced analysis. In order to do DHCPv6-only operation, you need to modify clients such = that they have some way other than RAs to determine which configuration = method(s) they are to use. That is a fundamentally incompatible and = dangerous change that could definitely have negative impacts. > If you have an opinion that is a useless activity - absolutely fine. To say the least. However, useless isn't enough to make me oppose it. I = oppose it because beyond useless, it is also potentially dangerous. >> Personally, I would much rather see us focus on the following easily = achievable goals that I think matter to a lot more people: >> 1. Provide more consistent guidance on the interactions of M, O, and = A flags in RAs and how RAs should be processed. >=20 > This is great - (though, if we were to use the argument you used = previously - why bother ? it will anyway take forever to achieve the = consistency). Documenting the existing behavior is a great start, = anyway. draft-ietf-v6ops-dhcpv6-slaac-problem is awesome. Because this actually impacts MANY organizations and users and is = becoming a bigger problem, not a smaller one. >> 2. Provide more consistent guidance on the interactions of RAs that = disagree. While this is arguably a "broken network" >> condition, it is a form of brokenness where having a defined and = deterministic mode of failure is more desirable than >> the current "depends on the host OS, phase of the moon, and 2d20 roll = of the operator" scenario. >=20 > This is indeed a broken network. >=20 > Use router priorities - it's an existing and deployed mechanism which = trivially resolves the conflicts with no ambiguity and no code changes = required. (Of course, assuming the host implements them and implements = correctly). People make typos. Router configurations get out of sync. This is the = real world. Knowing in advance how a host is going to deal with two = routers of equal priority giving different messages would be useful. = Having all hosts do the same thing would be even more useful, no? >> 3. Add routing information to DHCP for those that want to use it. >=20 > It will end up in the threads exactly like this one, just with = different people. It certainly has many times before. But at least that would be a useful = feature that doesn't break anything. Owen --Apple-Mail=_1F986388-D833-4051-A4EA-E0C6EF326683 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
     That the price = varies for different parties is a different matter.
Fair enough, but = it's free or very nearly free for the vast majority of = parties.

You need to take care:

1) that the = RAs from the router reach the = hosts.

If they don't, you have a = broken network and your other packets likely aren't reaching those = hosts, either. Beyond that, that's why things get = retried.

At least in the case of RAs, they only = have to travel a single hop. DHCP is often much more remote. At its = best, DHCP cannot be any better than in this = regard.

2) that only = the RAs from *your* router reach the = hosts.

This is no different = from the rogue DHCP server problem, so I am again, not impressed. An RA = attacker has to be on-link. If you have hostile hosts on-link in your = LAN, then you have bigger problems than rogue RA in most = cases.

either = of the two may be a non-issue for *you* but the induction that it's a = non-issue for *everyone* is = incorrect.

It's not a non-issue, = but DHCP has the same problems.




         &n= bsp;           &nbs= p; There is no single answer to why people might resist deploying = IPv6, no single solution, and things = that
           =             mo= tivate people to deploy or not IPv6 may have nothing to do with how IPv6 = itself = works.

          =             &n= bsp;      I think in this discussion are = again getting into the argument of "the best solution" instead = of
           &n= bsp;           &nbs= p;     trying to collect the properties of the = RA and = DHCP.
           = ;            &= nbsp;     My position is that single best = solution does not exist, = because

          = ;            &= nbsp;      everyone's problems are = slightly different. So, rather than preaching for everyone to adopt = the
           &= nbsp;           &nb= sp;     single solution which is the best in = one scenario and suboptimal in the other, we should = be
           &n= bsp;           &nbs= p;     engineering a way to be able to apply = different solutions in different circumstances without = the
           &= nbsp;           &nb= sp;     overhead of double = work.

          &= nbsp;           &nb= sp;A single solution that solves most cases is better than two = different,

         &n= bsp;       That's the point. The = single solution that solves most cases, does not exist. For a good part = of the cases, you need = to
           &n= bsp;     apply two solutions at once. = Justifiably, the question is "why", given in legacy IP they did not need = to do = that.

          &= nbsp;Actually, the problem is that people have conflated two different = problems and like to pretend that they are = one.

          &n= bsp;In fact, RAs solve 1.5 problems and DHCPv6 solves 1 = problem.

         &nbs= p; RAs solve the problem of telling a host which routers are = available on = link.
           = ;RAs also sort of solve the problem of dynamic host configuration = (address, RDNS servers, DNS Search = list)

          &= nbsp;For better or worse, to keep RAs very light weight, they do not = provide a complete or robust solution to host = autoconfiguration.

        =    For that, you need DHCPv6 which is a protocol designed = to do host configuration.

     I think = you nailed it here: With RA you *discover* the routers available on the = link, with DHCP in legacy IP, you *configure* them.
No, with DHCP, = you discovered what some remote host rumored them to = be.

     In some case you don't want the = hosts to "discover" anything - your network does not change, you know = your router, and actually having a way = to
     *configure* it is more robust and = secure than having to *discover* it. Why take away the tool from the = toolbox ?
Your host is always discovering things. IP doesn't work = without discovery (at least not in any practical way for the vast = majority of applications). In IPv4,
ARP is used to discover the MAC = address of adjacent hosts, for example. In IPv6, we use Neighbor = Solicitation and Neighbor Advertisement to do roughly the = same
thing.
There are a number of advantages to finding out what = routers are available to you FROM THE ROUTERS instead of getting rumors = from some remote server which may
or may not be accurate in general = and certainly have a reasonable chance of being flat out wrong in the = event of any failure condition.
A network that doesn't change is an = amusing fallacy. I will agree that there are some networks which don't = change until they do. However, I have yet to see a
network that = didn't change.

There are a number of advantages to = NOT finding out from the routers that they are the routers in an = unauthenticated manner.

Then use = SEND or turn of RA on your routers and deal with the consequences of = having to statically configure routes on every host and/or run a routing = protocol on every host.

I don't see any = advantage to a route from an unauthenticated DHCP server over a route = from an unauthenticated router.

The environments = vary.

Sure, but the basic = principles involved do not.

     Thanks for this, I = think this is a very valuable point, I'll add it to the text - https://github.com= /ayourtch/ra-dhcpv6/issues/9
If you do so, please do not = misconstrue my remarks the way you have in this = case.


Okay, I will not add you to the = "acknowledgements", and will treat that idea as my own, = FWIW.

So you think it is better to = misquote me out of context without attribution than to simply not = misquote me out of context? Somehow I don't really see that as an = improvement.

          =  While I would like to see routing options added to DHCP for a = variety of reasons (mostly political and organizational rather = than
           = technical), I do not for one second believe that eliminating RAs is = useful in any significant proportion of = environments.
         &nb= sp; Even if we made the changes you are proposing, eliminating RAs = would be unlikely in the vast majority of circumstances, at least = for
           m= any years to come.

     First off, I am = not proposing to eliminate the RAs, at least not just yet. :-)
I = didn't mean eliminating them in general. I meant that I am very hard = pressed to imagine any scenario where a network would benefit from = eliminating them
other than certain environments that would probably = be better suited to 6LOWPAN anyway.

Did you read the = draft mentioned in the subject line = ?

Yes, but I did not find it = compelling.

     I am proposing to = stop blindly repeating "thou shall not eliminate RAs" mantra and explore = with an open mind, what are the drivers behind = people
     wanting to use DHCP-only, how = hard would that be, and see on balance whether the juice is worth the = squeeze.
I've been through that exercise. I'm all for giving DHCP the = ability to provide routing information. I've said as much on numerous = occasions.
However, even on a network that is running "DHCP only" you = gain nothing (at least in the vast majority of circumstances) and lose = significant robustness if you
turn off = RAs.

Legacy IP runs fine with no RAs. Quite = robustly.

Legacy IP has numerous = problems, actually. We've gotten used to coping with them. The fact that = we have come to accept chronic pain is not a valid reason to avoid = seeking proper medical treatment. Indeed, most of the problems you claim = are specific to RA have variants that apply equally strongly to DHCP in = both IPv6 and in Legacy IP.

    =  Second, there are no IPv6-only enterprise networks today, so = eliminating RA would be *trivial* in those environments that want to = eliminate them,
     as soon as 1-2 = mainstream OSes were to support it.
That isn't true. I doubt = seriously that there are no IPv6-only enterprise networks, but I accept = that there are very few.
However, eliminating RA in those = environments that want to eliminate them would not be trivial. You'd = have to upgrade every desktop OS and every other
dynamically = configured device because in the current running code, DHCP doesn't work = without an RA to tell it "go ask the DHCP = server".

My OS upgrades itself every other week. And = installs apps, bugfixes, and such. Autoupdate exists and works. In a = stricter environment you have an IT department building the golden = setups. The image lifecycle there is = 3-5
years.

I'm happy for you, = but that's not the case for the vast majority of enterprises where = Windows "autoupdate" is not so well = trusted.

Talk to any IT department in any = organization of substantial size and ask them if they have complete 100% = control over the update cycle of absolutely every machine on the = network. I'm willing to bet that not one of them can honestly answer = that question in the affirmative. There's always some piece of software = that someone deems critical to the enterprise at a high enough level = which can't be updated for some reason. The longer an enterprise is in = business and the larger it becomes, the more of these exceptional cases = emerge.

     How ? Much the same as with = DHCPv6-only networks today. Don't support the network's policy ? Fine, = you are welcome to use your legacy IP = stack
     until you do.
There are no = DHCPv6-only networks today.

I was using one just on = Friday.

How did you get the clients = to ask the DHCP server for something without giving it an M|O Bit = RA?

Arguably, said clients are not behaving = according to the RFCs.

     And in any case = "taking many years to come" is not an argument for not doing = things.
It is an argument against putting significant risk into a = deployed codebase for a minuscule gain for a very small number of = beneficiaries.

     Case in point: IPv6 = itself.
IPv6 itself didn't involve deploying incompatible updates = that will potentially interfere with a deployed operational = protocol.

IPv6 is completely incompatible with the = deployed operational IPv4, and in the rfc3484 case a broken IPv6 = completely screws up your perfectly working = IPv4.

No, IPv6 is a completely = separate protocol. Yes, there are certain ways to break name resolution = for IPv4 with IPv6 misconfiguration, but that is because of the shared = name service. IPv6 the protocol does _NOT_ interfere with IPv4 the = protocol on the wire. The issues in RFC3484 are entirely related to DNS = being shared between the two protocols.

The changes = you are proposing
(to make hosts do DHCP without bootstrapping it = through the RA process) are different. Those are not at all unlikely to = be problematic in a number of difficult
to predict = ways.

Again, all I am proposing is to decriminalize = the thinking about proposing DHCPv6-only operation and its implications, = and be able to write it up for further balanced = analysis.

In order to do = DHCPv6-only operation, you need to modify clients such that they have = some way other than RAs to determine which configuration method(s) they = are to use. That is a fundamentally incompatible and dangerous change = that could definitely have negative impacts.

If you have an opinion that is a = useless activity - absolutely = fine.

To say the least. However, = useless isn't enough to make me oppose it. I oppose it because beyond = useless, it is also potentially dangerous.

Personally, I = would much rather see us focus on the following easily achievable goals = that I think matter to a lot more people:
1. Provide more consistent = guidance on the interactions of M, O, and A flags in RAs and how RAs = should be processed.

This is great - (though, if we = were to use the argument you used previously - why bother ? it will = anyway take forever to achieve the consistency). Documenting the = existing behavior is a great start, anyway. = draft-ietf-v6ops-dhcpv6-slaac-problem is = awesome.

Because this actually = impacts MANY organizations and users and is becoming a bigger problem, = not a smaller one.

2. Provide more consistent guidance on = the interactions of RAs that disagree. While this is arguably a "broken = network"
condition, it is a form of brokenness where having a defined = and deterministic mode of failure is more desirable than
the current = "depends on the host OS, phase of the moon, and 2d20 roll of the = operator" scenario.

This is indeed a broken = network.

Use router priorities - it's an existing and deployed = mechanism which trivially resolves the conflicts with no ambiguity and = no code changes required. (Of course, assuming the host implements them = and implements correctly).

People = make typos. Router configurations get out of sync. This is the real = world. Knowing in advance how a host is going to deal with two routers = of equal priority giving different messages would be useful. Having all = hosts do the same thing would be even more useful, = no?

3. Add routing information to DHCP for those that want to = use it.

It will end up in the threads exactly like = this one, just with different = people.

It certainly has many times = before. But at least that would be a useful feature that doesn't break = anything.

Owen

= --Apple-Mail=_1F986388-D833-4051-A4EA-E0C6EF326683-- From owen@delong.com Sun Dec 8 11:42:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1467E1AE0AE for ; Sun, 8 Dec 2013 11:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt0U4X1daN8Q for ; Sun, 8 Dec 2013 11:42:42 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0591AE0AD for ; Sun, 8 Dec 2013 11:42:41 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB8JeRJi015114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Dec 2013 11:40:27 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB8JeRJi015114 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386531627; bh=4nDTfepdPKVSr8RzUsNRpBKfiPU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ak1gOrHyoZyeG5C400CE44EyAlUa3ltQTBVtT5X7285ZenKM66ziziLArqvVluEKR ZOsaFzKbcPLdJ9x+cUaxXaDpPqBGIlInDHl4Ki8cI95uaus3H2rH32lS9hlogWnDHc m94+HGDAnKCvcCf5lF3LXJKHoAR5YWSABE8QxgpI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52A4C6FD.1080504@gmail.com> Date: Sun, 8 Dec 2013 11:38:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sun, 08 Dec 2013 11:40:27 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 19:42:43 -0000 On Dec 8, 2013, at 11:22 , Brian E Carpenter = wrote: > On 08/12/2013 19:40, Owen DeLong wrote: >> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko = wrote: >=20 > ... >>> I think you nailed it here: With RA you *discover* the routers = available on the link, with DHCP in legacy IP, you *configure* them. >>=20 >> No, with DHCP, you discovered what some remote host rumored them to = be. >=20 > I don't think we should be having this argument. We should be > trying to write down objectively the type of scenarios where > DHCPv6 is applicable, the type of scenarios where RA-only is > applicable, and the type of scenarios where both (simultaneously) > are applicable. >=20 > There's no right or wrong answer here. >=20 > Brian In IPv6, as I read the RFCs, there's no valid way for a host to know = that it is supposed to get information from a DHCPv6 server unless it = receives an RA with the M and/or O bits set. As such, the options are not DHCPv6 only, RA-only, and Both, but, = RA-only and Both. The scenarios where RA-Only make sense are any scenario where you do not = need greater control of the client configuration than Prefix = information, routing information, and DNS resolver addresses and search = strings. In any scenario where you need to supply the host with more = configuration information on a dynamic basis, DHCPv6 is also required. Also, if you want dynamic DNS updates, deterministic assigned suffixes, = etc., these fall into the DHCPv6 realm. It's really as simple as that as near as I can tell. If you want to run without RAs, then you are into the realm of static = configuration. I, personally, do not see this as a problem. Owen From markzzzsmith@yahoo.com.au Sun Dec 8 12:05:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D4D1AE0C8 for ; Sun, 8 Dec 2013 12:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tLg6elPA20t for ; Sun, 8 Dec 2013 12:05:58 -0800 (PST) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with SMTP id EDAE01AE0B8 for ; Sun, 8 Dec 2013 12:05:57 -0800 (PST) Received: from [98.139.212.152] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 08 Dec 2013 20:05:53 -0000 Received: from [98.139.212.211] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 08 Dec 2013 20:05:53 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 08 Dec 2013 20:05:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 361307.23641.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 54810 invoked by uid 60001); 8 Dec 2013 20:05:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1386533153; bh=Rujo0IHr4fMhhsq9JxEvoP012XNpSHlHL5RA15Luvz8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cHIDDET2nK+OvYhA57k8B/pOZ+SYP0N7AVMG+4zafln48NGQgMon2xQ6XN+0b/5PYP6sM9CTbh5WoW2KNEafnWgRUUGwQcLqYz/N3BD/PevALltdisM7lVlDjMDSyxzzXMuBBNWhAiSjP09LPBE19alg3mI0uAHLTBsqe2qNJKM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tgI3JygX7h7+c6xm8HPgqWGa2VrUBnF9v5XEUavn6jIPALxEt+YIAiyCa8EhXhNPM6+HOm6lbgNH601bIbvEbVK32Gx5nVwGrNh/sbEWsWwbF05iRZx1/zoH9r/Vy6H0nPFmwlE1+XTQiCIrD/3UwydosP2aHjdJfwFDbfSHS5U=; X-YMail-OSG: mUPgV8UVM1leNelVu_vY938_2pQqzXlSfYAWlshmb0K5MYZ 7K9o5ql.iSU5PhIYDbCNK9DQBViUXWjEjhcySZ59ePPHRvzq9xdu3QQK58kr _JwjynZ2fm.HEXktzCaYg0GE7GupeSvekEO9q8sfhIkm8nFveROgAVz6mFq5 XSRB3ZZS3eFEyMiJtqS8Tf0qfvK4CQEvoSifKkXozscuUkp3HTV5k4JCiDkR GUnDgxmy8ME4aPXZrCznaY3jcXRvX1ikES2z4mhrOH7Hy6fIBk9gYd2.Rgv_ hceNKNk_R9zuBsrsgL9VzFd3sUAVUZfnQSwzoyOkVd.p38yGh5cYYoTJPVdQ C6hzAGjI3b1Vd.8ihXWwMVhz7mA.FCXn4N60yt0ry7W3EUtiy1yy9GhyL7Cv Fzs_BBjzoqmgA5hK4zTo.IJmLK5nO1rHLCCiihH6wGtcB23KR0UcIx0fXAbO gWBfe0LgKAlk0pplJHUqAA068ZTS8bTnfU8ti5gB8sJJ0H1AAP1ae0LNVSR9 EZFNvUv_UjaWQirgb7.X8L07IG5Tsvmxl_xP9XLBpO.vebqIxx18uuI_jsFD quvktcRkT30VyaIXAsXtJ Received: from [150.101.221.237] by web161905.mail.bf1.yahoo.com via HTTP; Sun, 08 Dec 2013 12:05:52 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT4KPiBUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4KPiBDYzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogU3VuZGF5LCA4IERlY2VtYmVyIDIwMTMgNTo0NCBQTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW91cnRjaGVua28tcmEtZGhjcHY2LWNvbXBhcmkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> Message-ID: <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> Date: Sun, 8 Dec 2013 12:05:52 -0800 (PST) From: Mark ZZZ Smith To: Andrew Yourtchenko , "Bernie Volz \(volz\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 20:05:59 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Andrew Yourtchenko =0A> To: Bernie Volz (volz) =0A> Cc: "v6ops@= ietf.org" =0A> Sent: Sunday, 8 December 2013 5:44 PM=0A> Su= bject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6= -comparison-00.txt (fwd)=0A> =0A> On Sun, 8 Dec 2013, Bernie Volz (volz) wr= ote:=0A> =0A>>>=A0=A0While I would like to see routing options added to DHC= P for a variety =0A> of reasons (mostly political and organizational rather= than technical), I do not =0A> for one second believe that eliminating RAs= is useful in any significant =0A> proportion of environments.=0A>> =0A>>= =A0=A0Yeah, I don't think they should go either.=0A> =0A> Again, I am *not*= proposing to deprecate them.=0A> =0A> I'm proposing to decriminalize the t= hinking of allowing to not use them.=0A=0A=0AFirstly, please stop using hyp= erbolic words such as "decriminalize" unless you actually mean them. I'd st= art to doubt your ability to create a balanced document if you think people= advocating for leaving things as they are to be accusing others who want t= o change things to be criminals. It makes you sound like you're extremely s= ubjective about this topic, and therefore will end up with an agenda to dis= tort arguments against doing it to support your view.=0A=0APeople who reall= y don't like RAs can switch them off and use static configuration. They can= also switch off neighbor discovery and manually configure that to eliminat= e ND multicasts, and configure static multicast group membership to elimina= te MLD multicasts. If their complaint is RA multicasts (which can be up to = 30 minutes apart per the RFC advertisement interval), then I think their ac= tual complaint is or should be all multicasts.=0A=0AThe point of RAs and DH= CPv6 is automated configuration. To make automation work reliably you need = to minimise and ideally remove options and parameters, because options and = parameters can require human beings to make choices and to get them right, = and that creates opportunities for human error. This includes errors in imp= lementations of mechanisms to negotiate methods, options or parameters (see= issues with misinterpretation of and between the M/O RA and PIO A options = in "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", draf= t-liu-bonica-dhcpv6-slaac-problem, as an example.)=0A=0ATechnical people li= ke choice and flexibility, because I think they think about "what ifs" - "w= hat if I was in this situation, what if I was in that situation, and what w= ould I like to tweak to make it work." Non-technical end-users (usually our= customers or at least our relatives), who far surpass us in numbers, don't= care, shouldn't care and shouldn't have to care. They just want it to work= , work reliably, and don't want to have to engage technical people to eithe= r make it work or call in assistance if it doesn't work or stops working. C= hoices, options and parameters make things more complex and therefore more = fragile and less robust.=0A=0AWe currently have a single mechanism to annou= nce a default gateway, and the default gateway announces itself, out of the= box. That makes it pretty hard, if not impossible for that information to = be wrong.=A0DHCPv6 for default gateways would in the DHCPv6 relay scenario = would require human entry of that information, creating the opportunity for= human error, and potential conflict with what RAs are announcing.=0A=0AReg= ards,=0A=0AMark.=0A=A0=0A=0A> --a=0A> =0A>> =0A>>=A0=A0- Bernie=0A>> =0A>>= =A0=A0-----Original Message-----=0A>>=A0=A0From: v6ops [mailto:v6ops-bounce= s@ietf.org] On Behalf Of Owen DeLong=0A>>=A0=A0Sent: Saturday, December 07,= 2013 4:23 PM=0A>>=A0=A0To: Andrew Yourtchenko (ayourtch)=0A>>=A0=A0Cc: v6o= ps@ietf.org=0A>>=A0=A0Subject: Re: [v6ops] New Version Notification for =0A= > draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)=0A>> =0A>>>>=A0=A0I d= on't think RAs are the single reason some people are =0A> resisting deployi= ng IPv6 at all. I think some people are resisting deploying =0A> IPv6 becau= se it needs to do one or both of two things for them - solve a =0A> foresee= able problem that will effect them, or provide a tangible benefit. If it = =0A> won't do either of those things, then they don't currently see any val= ue =0A> from the effort involved. What are foreseeable problems or tangible= benefits is =0A> completely up to the perspective of the decision maker. E= ventually they'll =0A> see value in it, and deploy it. In some cases, some = people who could deploy IPv6 =0A> may never see any value in deploying it, = so they never will.=0A>>> =0A>>>=A0=A0It's not binary. You can represent as= a number both the amount of =0A> pain that a given problem (or set of prob= lems) causes, and the amount of pain =0A> that the big change in the networ= k like adding a new protocol causes.=0A>>> =0A>>>=A0=A0As soon as the first= number is smaller than the second one, nothing =0A> gets done.=0A>>> =0A>>= >=A0=A0Judging by the feedback I get from talking with people, even the =0A= > possibility of eventually eliminating RAs from their network might make t= he =0A> second number smaller for a nontrivial amount folks, whose situatio= n dictates =0A> the DHCPv6.=0A>>> =0A>> =0A>>=A0=A0I find this very hard to= believe. RAs are virtually automatic and free in =0A> 99% of cases. If you= feel the need to tune them, then that's pretty trivial =0A> if you know en= ough to tune them properly.=0A>> =0A>>=A0=A0If you don't know what you are = doing, then you can really mess yourself =0A> up with RA tweaking that you = shouldn't be doing.=0A>> =0A>>=A0=A0However, I do not advocate IETF breakin= g the internet just to prevent =0A> people from breaking their LANs out of = ignorance.=0A>> =0A>>>>=A0=A0There is no single answer to why people might = resist deploying =0A> IPv6, no single solution, and things that motivate pe= ople to deploy or not IPv6 =0A> may have nothing to do with how IPv6 itself= works.=0A>>>> =0A>>>> =0A>>>> =0A>>>>>=A0=A0I think in this discussion are= again getting into the argument =0A> of "the best solution" instead of try= ing to collect the properties of =0A> the RA and DHCP.=0A>>>>>=A0=A0My posi= tion is that single best solution does not exist, =0A> because=0A>>>> =0A>>= >>>=A0=A0everyone's problems are slightly different. So, rather than =0A> p= reaching for everyone to adopt the single solution which is the best in one= =0A> scenario and suboptimal in the other, we should be engineering a way = to be able =0A> to apply different solutions in different circumstances wit= hout the overhead of =0A> double work.=0A>>>> =0A>>>>=A0=A0A single solutio= n that solves most cases is better than two =0A> different,=0A>>> =0A>>>=A0= =A0That's the point. The single solution that solves most cases, does =0A> = not exist. For a good part of the cases, you need to apply two solutions at= =0A> once. Justifiably, the question is "why", given in legacy IP they did= =0A> not need to do that.=0A>> =0A>>=A0=A0Actually, the problem is that pe= ople have conflated two different problems =0A> and like to pretend that th= ey are one.=0A>> =0A>>=A0=A0In fact, RAs solve 1.5 problems and DHCPv6 solv= es 1 problem.=0A>> =0A>>=A0=A0RAs solve the problem of telling a host which= routers are available on =0A> link.=0A>>=A0=A0RAs also sort of solve the p= roblem of dynamic host configuration (address, =0A> RDNS servers, DNS Searc= h list)=0A>> =0A>>=A0=A0For better or worse, to keep RAs very light weight,= they do not provide a =0A> complete or robust solution to host autoconfigu= ration.=0A>>=A0=A0For that, you need DHCPv6 which is a protocol designed to= do host =0A> configuration.=0A>> =0A>>=A0=A0While I would like to see rout= ing options added to DHCP for a variety of =0A> reasons (mostly political a= nd organizational rather than technical), I do not =0A> for one second beli= eve that eliminating RAs is useful in any significant =0A> proportion of en= vironments. Even if we made the changes you are proposing, =0A> eliminating= RAs would be unlikely in the vast majority of circumstances, at =0A> least= for many years to come.=0A>> =0A>>=A0=A0Owen=0A>> =0A>> =0A>>=A0=A0_______= ________________________________________=0A>>=A0=A0v6ops mailing list=0A>>= =A0=A0v6ops@ietf.org=0A>>=A0=A0https://www.ietf.org/mailman/listinfo/v6ops= =0A>> =0A> _______________________________________________=0A> v6ops mailin= g list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops= =0A> =A0 From brian.e.carpenter@gmail.com Sun Dec 8 13:14:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31EB1AE0FC for ; Sun, 8 Dec 2013 13:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTXRO5Z99ZZv for ; Sun, 8 Dec 2013 13:14:40 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C0D7D1AE0E2 for ; Sun, 8 Dec 2013 13:14:40 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rr13so4127037pbb.37 for ; Sun, 08 Dec 2013 13:14:36 -0800 (PST) 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=4e1dGuEzXEelEiHy+/m3qAw5Zf/bXsKFlo6RwdsgsT4=; b=xNdOBSyY5/W+vDDRPi7c8wkL3qslx0Rr1sEBPHBzB4akO3Zggtx/8HW+rZivpCMOJw Tpcke36PAaza6jvlFTOvB1lXH4z65nWHKXHyadW7OA7fQezQQ7F2uglcIaU6scFCQhvc 0NwoDtSLuy8kz2HXMAaAb/hICOOlGSPK+q75HjX3ay4OvSzlAjRyhhzEr3I+19LCoP/0 xopkPN6v9lwYo2YWACK9ytFlrNyjxuITydVaEDxje/xHONf+bUvRpmS5WNACMONwnFP/ Py8QqyNgjNGNrFF6vH8M2I8/Z5/K9z/mCdQY1wZ4N1ZtQTJ/yiKaLytgj+VaDT2snpvC HVaA== X-Received: by 10.66.27.177 with SMTP id u17mr16828498pag.25.1386537276329; Sun, 08 Dec 2013 13:14:36 -0800 (PST) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id xv2sm12950837pbb.39.2013.12.08.13.14.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Dec 2013 13:14:35 -0800 (PST) Message-ID: <52A4E138.7030906@gmail.com> Date: Mon, 09 Dec 2013 10:14:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52A4C6FD.1080504@gmail.com> <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> In-Reply-To: <98CACA9B-AD61-460A-93AC-D5EEA1176706@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 21:14:42 -0000 On 09/12/2013 08:38, Owen DeLong wrote: > On Dec 8, 2013, at 11:22 , Brian E Carpenter wrote: > >> On 08/12/2013 19:40, Owen DeLong wrote: >>> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko wrote: >> ... >>>> I think you nailed it here: With RA you *discover* the routers available on the link, with DHCP in legacy IP, you *configure* them. >>> No, with DHCP, you discovered what some remote host rumored them to be. >> I don't think we should be having this argument. We should be >> trying to write down objectively the type of scenarios where >> DHCPv6 is applicable, the type of scenarios where RA-only is >> applicable, and the type of scenarios where both (simultaneously) >> are applicable. >> >> There's no right or wrong answer here. >> >> Brian > > In IPv6, as I read the RFCs, there's no valid way for a host to know that it is supposed to get information from a DHCPv6 server unless it receives an RA with the M and/or O bits set. > > As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only and Both. Two comments on that: a) Yes, where I wrote DHCPv6, I should have written "DHCPv6 with minimal RA", with "Both" implying more-than-minimal RA. b) IMHO we need to fix the ambiguity caused by the M/O bits' current definition. http://tools.ietf.org/html/draft-liu-6renum-dhcpv6-slaac-switching In any case I'd like to see neutral analysis in the draft. Brian > The scenarios where RA-Only make sense are any scenario where you do not need greater control of the client configuration than Prefix information, routing information, and DNS resolver addresses and search strings. > > In any scenario where you need to supply the host with more configuration information on a dynamic basis, DHCPv6 is also required. > > Also, if you want dynamic DNS updates, deterministic assigned suffixes, etc., these fall into the DHCPv6 realm. > > It's really as simple as that as near as I can tell. > > If you want to run without RAs, then you are into the realm of static configuration. I, personally, do not see this as a problem. > > Owen > > From Ted.Lemon@nominum.com Sun Dec 8 14:31:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D51AE139 for ; Sun, 8 Dec 2013 14:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO5s82FdIUtb for ; Sun, 8 Dec 2013 14:31:43 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 03E481AE128 for ; Sun, 8 Dec 2013 14:31:42 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUqTzSoVl2+foppS9ynijiHqelLV0hrIY@postini.com; Sun, 08 Dec 2013 14:31:38 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4B8191B8292 for ; Sun, 8 Dec 2013 14:31:38 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 25AD1190043; Sun, 8 Dec 2013 14:31:38 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 8 Dec 2013 14:31:37 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> Date: Sun, 8 Dec 2013 17:31:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <4193B4FE-C3AB-4D4E-855F-C430ECCEB790@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 22:31:44 -0000 On Dec 8, 2013, at 3:05 PM, Mark ZZZ Smith = wrote: > Firstly, please stop using hyperbolic words such as "decriminalize" = unless you actually mean them. First of all, I agree with this. But secondly, let me point out that = it is not a surprising thing to hear, because the debate on this has = been fairly emotional. I absolutely agree that we should keep this on = a technical level, but please be understanding if the occasional = reference to the painful history of this discussion pops out. From ayourtch@cisco.com Sun Dec 8 16:33:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82121AE12C for ; Sun, 8 Dec 2013 16:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xntVpLiT61Vy for ; Sun, 8 Dec 2013 16:33:02 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AFE141AE11E for ; Sun, 8 Dec 2013 16:33:01 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB90Wui1007449 for ; Mon, 9 Dec 2013 01:32:56 +0100 (CET) Received: from ams-ayourtch-8711.cisco.com (ams-ayourtch-8711.cisco.com [10.55.144.242]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB90Wpxq008886; Mon, 9 Dec 2013 01:32:52 +0100 (CET) Date: Mon, 9 Dec 2013 01:32:28 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Ted Lemon In-Reply-To: <4193B4FE-C3AB-4D4E-855F-C430ECCEB790@nominum.com> Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> <4193B4FE-C3AB-4D4E-855F-C430ECCEB790@nominum.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 00:33:03 -0000 On Sun, 8 Dec 2013, Ted Lemon wrote: > On Dec 8, 2013, at 3:05 PM, Mark ZZZ Smith wrote: >> Firstly, please stop using hyperbolic words such as "decriminalize" unless you actually mean them. > > First of all, I agree with this. But secondly, let me point out that >it is not a surprising thing to hear, because the debate on this has been >fairly emotional. I absolutely agree that we should keep this on a >technical level, but please be understanding if the occasional reference >to the painful history of this discussion pops out. > My apologies for what apparently is an excessively strong language. English is my second language (albeit an old-time one, so it's hardly an excuse) and sometimes I can't measure correctly the exact impact my words may have. Sorry for this. I don't have a hidden agenda to make RAs obsolete. I have closed the issue on the github which caused the contention with Owen and will not pursue that area in the draft to avoid any conflict. I'll make the edits to clear out the other outstanding issues, submit a new rev for the draft - and will leave it as such - just a URL to the draft is more than good enough to be used for referencing. --a From ayourtch@cisco.com Sun Dec 8 16:36:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAFB1AE12F for ; Sun, 8 Dec 2013 16:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m13qV8v3BvJv for ; Sun, 8 Dec 2013 16:36:52 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 14F9D1AE118 for ; Sun, 8 Dec 2013 16:36:51 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB90akHv007779 for ; Mon, 9 Dec 2013 01:36:46 +0100 (CET) Received: from ams-ayourtch-8711.cisco.com (ams-ayourtch-8711.cisco.com [10.55.144.242]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB90aflg009929; Mon, 9 Dec 2013 01:36:42 +0100 (CET) Date: Mon, 9 Dec 2013 01:36:18 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Mark ZZZ Smith In-Reply-To: <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2001112970-1386549378=:83043" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 00:36:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2001112970-1386549378=:83043 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 8 Dec 2013, Mark ZZZ Smith wrote: > People who really don't like RAs can switch them off and use static configuration. They can also switch off neighbor discovery and manually configure that to eliminate ND multicasts, and configure static multicast group membership to eliminate MLD multicasts. If their complaint is RA multicasts (which can be up to 30 minutes apart per the RFC advertisement interval), then I think their actual complaint is or should be all multicasts. > > The point of RAs and DHCPv6 is automated configuration. To make automation work reliably you need to minimise and ideally remove options and parameters, because options and parameters can require human beings to make choices and to get them right, and that creates opportunities for human error. This includes errors in implementations of mechanisms to negotiate methods, options or parameters (see issues with misinterpretation of and between the M/O RA and PIO A options in "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", draft-liu-bonica-dhcpv6-slaac-problem, as an example.) > > Technical people like choice and flexibility, because I think they think about "what ifs" - "what if I was in this situation, what if I was in that situation, and what would I like to tweak to make it work." Non-technical end-users (usually our customers or at least our relatives), who far surpass us in numbers, don't care, shouldn't care and shouldn't have to care. They just want it to work, work reliably, and don't want to have to engage technical people to either make it work or call in assistance if it doesn't work or stops working. Choices, options and parameters make things more complex and therefore more fragile and less robust. > > We currently have a single mechanism to announce a default gateway, and the default gateway announces itself, out of the box. That makes it pretty hard, if not impossible for that information to be wrong. DHCPv6 for default gateways would in the DHCPv6 relay scenario would require human entry of that information, creating the opportunity for human error, and potential conflict with what RAs are announcing. All very good points. I agree with the majority of them. Thanks a lot for the discussion. --a --0-2001112970-1386549378=:83043-- From internet-drafts@ietf.org Sun Dec 8 19:37:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A271A1F3E; Sun, 8 Dec 2013 19:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW38lzbLWfCc; Sun, 8 Dec 2013 19:37:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 446081AE1D3; Sun, 8 Dec 2013 19:37:34 -0800 (PST) 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 X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> Date: Sun, 08 Dec 2013 19:37:34 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 03:37:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experience Author(s) : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-05.txt Pages : 21 Date : 2013-12-08 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From phdgang@gmail.com Sun Dec 8 19:48:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532291A1F7C for ; Sun, 8 Dec 2013 19:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_PnKDgl7Mb4 for ; Sun, 8 Dec 2013 19:48:49 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 61E9A1A1F3E for ; Sun, 8 Dec 2013 19:48:49 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id e16so2318135qcx.31 for ; Sun, 08 Dec 2013 19:48:44 -0800 (PST) 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=h7hF4yClmbp7PhdZdt0gYDuMJ/ciO5TczFmlpykqcXw=; b=yuaUrearBstHEzGu8I8nLkwhkyNuctsShOSVE3ePEjatJo/vA9INazkViy4hSsuecv 8sJgETzLcpZKhaeWefuUMlwCA0pYpayw+lP0IFnkyz06GOuTLj8N5iF1enpLXCXmxw+b WMJig3vpDM3nacT45GCoIjnNN9Mue6HtEaCQkZtA1EPIJ4WAigPO5RfSlGPZUDsXVBwA NY+dhSfdOE/gs2omt+Iy3lf7s9vZtoamQCxVETOZd7oxE6SXWVLBCCOXnhE4kwJeO/9w vdAK4YasT9GolMXvlrpuYdLjz/tUCa+lZc2Ghzj+32cgcdGmWOHvY7YyLolSwCDJr5bE YYiw== MIME-Version: 1.0 X-Received: by 10.49.132.65 with SMTP id os1mr163585978qeb.39.1386560924518; Sun, 08 Dec 2013 19:48:44 -0800 (PST) Received: by 10.224.172.135 with HTTP; Sun, 8 Dec 2013 19:48:44 -0800 (PST) Date: Mon, 9 Dec 2013 11:48:44 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 03:48:51 -0000 Wg, We have submitted the new version of NAT64 Operational Experience. The updates are summarized as follows: 1) Clarify the case when NAT64 serves as the IPv6 gateway ( Sec. 3.1.2) 2) Polish the statement of NAT44 & NAT64 co-existing (Sec. 3.1.4) 3) Clarify that the sub-domain configuration is only for the experimental phase (Sec 3.2) 4) Share the data for the scale of sync data in hot standby (Sec 4.1) 5) Assessing the Impact of NAT64 to applications (Sec. 6.1) Your further reviews/comments are welcome. BRs Gang 2013/12/9, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : NAT64 Operational Experience > Author(s) : Gang Chen > Zhen Cao > Chongfeng Xie > David Binet > Filename : draft-ietf-v6ops-nat64-experience-05.txt > Pages : 21 > Date : 2013-12-08 > > Abstract: > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and > NAT64 server Front End (NAT64-FE) are considered in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Sun Dec 8 21:22:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BA71AD6BF for ; Sun, 8 Dec 2013 21:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvefFbeoWR6D for ; Sun, 8 Dec 2013 21:22:19 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 837271AC4A3 for ; Sun, 8 Dec 2013 21:22:18 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB95K8Cu021684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Dec 2013 21:20:09 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB95K8Cu021684 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386566410; bh=43+ScRHfm7u4IqGHO1BWr6+4T/w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Vtqj9vN/kd5F9NdxpNZ2jV1XOyO1uWQP+I4Gf7ArxpWnNJma45Dp4UFl+P9WhFrsC iJQwEKLCZuf63kaC3Fm/WJHEJDXSPG+SyIN3ZGwdshEesWqumSUrkNxO80f0OKLU1W riGQFhyeabEih31kqm8UMRa1kzjEtg5Emm/jP23g= Content-Type: multipart/alternative; boundary="Apple-Mail=_0ADCB716-1674-4015-8D0C-B3F9DBF2FD53" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> Date: Sun, 8 Dec 2013 21:20:06 -0800 Message-Id: <22BFD8E2-4406-46A8-93F2-702319C32344@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 08 Dec 2013 21:20:10 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 05:22:22 -0000 --Apple-Mail=_0ADCB716-1674-4015-8D0C-B3F9DBF2FD53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Technical people like choice and flexibility, because I think they = think about "what ifs" - "what if I was in this situation, what if I was = in that situation, and what would I like to tweak to make it work." = Non-technical end-users (usually our customers or at least our = relatives), who far surpass us in numbers, don't care, shouldn't care = and shouldn't have to care. They just want it to work, work reliably, = and don't want to have to engage technical people to either make it work = or call in assistance if it doesn't work or stops working. Choices, = options and parameters make things more complex and therefore more = fragile and less robust. I don=92t mind the flipper door, but I really hate it when people remove = all the knobs. (The non-technical users shouldn=92t open the flipper = door). > We currently have a single mechanism to announce a default gateway, = and the default gateway announces itself, out of the box. That makes it = pretty hard, if not impossible for that information to be wrong. DHCPv6 = for default gateways would in the DHCPv6 relay scenario would require = human entry of that information, creating the opportunity for human = error, and potential conflict with what RAs are announcing. It=92s not hard at all. All you have to do is put a router on the = network that is connected away from, instead of towards the internet and = voila, you have arguably =93wrong=94 RAs. This won=92t usually break anything because redirects usually work and = even if they don=92t, you just put unnecessary load on the network and = the router that can=92t forward the packets. However, if that router = doesn=92t know the correct address for the other routers, then your RAs = will be truly wrong and things do break. Owen --Apple-Mail=_0ADCB716-1674-4015-8D0C-B3F9DBF2FD53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Technical people like choice and = flexibility, because I think they think about "what ifs" - "what if I = was in this situation, what if I was in that situation, and what would I = like to tweak to make it work." Non-technical end-users (usually our = customers or at least our relatives), who far surpass us in numbers, = don't care, shouldn't care and shouldn't have to care. They just want it = to work, work reliably, and don't want to have to engage technical = people to either make it work or call in assistance if it doesn't work = or stops working. Choices, options and parameters make things more = complex and therefore more fragile and less = robust.

I don=92t mind the flipper = door, but I really hate it when people remove all the knobs. (The = non-technical users shouldn=92t open the flipper = door).

We = currently have a single mechanism to announce a default gateway, and the = default gateway announces itself, out of the box. That makes it pretty = hard, if not impossible for that information to be wrong. DHCPv6 = for default gateways would in the DHCPv6 relay scenario would require = human entry of that information, creating the opportunity for human = error, and potential conflict with what RAs are = announcing.

It=92s not hard at all. = All you have to do is put a router on the network that is connected away = from, instead of towards the internet and voila, you have arguably = =93wrong=94 RAs.

This won=92t usually break = anything because redirects usually work and even if they don=92t, you = just put unnecessary load on the network and the router that can=92t = forward the packets. However, if that router doesn=92t know the correct = address for the other routers, then your RAs will be truly wrong and = things do = break.

Owen


= --Apple-Mail=_0ADCB716-1674-4015-8D0C-B3F9DBF2FD53-- From marc.lampo.ietf@gmail.com Sun Dec 8 23:48:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335011ADEBF for ; Sun, 8 Dec 2013 23:48:38 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFI_hHAt-8bZ for ; Sun, 8 Dec 2013 23:48:35 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A50A41AE1DA for ; Sun, 8 Dec 2013 23:48:35 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so3204065veb.22 for ; Sun, 08 Dec 2013 23:48:30 -0800 (PST) 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; bh=AcOjfVSS4p3qWLmXkTAycaN7tZQwB0TcP59gGbk3sYs=; b=OyFAuAH9Qye2i9ZQUCvhVZNpnU/qc3OLrYQTuEarYXnjuOh/kqvgxHC8qJS0MAjJ5N RIPZW0+5Jsuy09oI7Vc1Cz/HeIEH3Zx2crr4/1PyO5iGcJJwoffjnehiYIzRohWHCpv8 nS3pNb3pWSK8vhmGl8A9J1KVNIHsb5lcf+0Fgr2PcuMfQw2kcOiYIDLc5Az/sPZzyllh nUIrGmWEXwThXZifFYHjgkSIjn58BfOExvtMqSwiyN7NcoTIZwvufZehgKuKKRXaLK+d p3tSZ9BMVnrJpTNE2cqBIl9Woidcah0O0OwX4h686axB2+Ppo55c57UVw7lWLQravCmw udSQ== MIME-Version: 1.0 X-Received: by 10.58.6.239 with SMTP id e15mr1119607vea.29.1386575310721; Sun, 08 Dec 2013 23:48:30 -0800 (PST) Received: by 10.58.227.66 with HTTP; Sun, 8 Dec 2013 23:48:30 -0800 (PST) In-Reply-To: References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> Date: Mon, 9 Dec 2013 08:48:30 +0100 Message-ID: From: Marc Lampo To: Guillaume Leclanche Content-Type: multipart/alternative; boundary=047d7b6d7f7ad998f504ed15387e Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 07:48:38 -0000 --047d7b6d7f7ad998f504ed15387e Content-Type: text/plain; charset=ISO-8859-1 Section 2, Threats, still lists 6 threats of which only one (the fourth) is addressed by the proposed implementation and then, only partially. In my opinion this is very misleading as Swisscoms customers might get the impression their ISP's approach helps against the 5 other threats as well, which it doesnot. I'd delete the section altogether. Kind regards, Marc On Fri, Dec 6, 2013 at 4:51 PM, Guillaume Leclanche wrote: > Hello, > > This is a new version of the draft after having analyzed the WGLC > comments and the Security Directorate review. > > A lot of text was modified to make sure that the document could not be > mistaken for a recommendation. The filtering concept and examples are > not changed, as the authors have chosen to stick to describing the > documented practice. > > There are new mentions of PCP and UPnP, and the Security > Considerations part was also detailed. > > Guillaume > > 2013/12/6 : > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > > > Title : Balanced Security for IPv6 Residential CPE > > Author(s) : Martin Gysi > > Guillaume Leclanche > > Eric Vyncke > > Ragnar Anfinsen > > Filename : draft-ietf-v6ops-balanced-ipv6-security-01.txt > > Pages : 9 > > Date : 2013-12-06 > > > > Abstract: > > This document describes how an IPv6 residential Customer Premise > > Equipment (CPE) can have a balanced security policy that allows for a > > mostly end-to-end connectivity while keeping the major threats > > outside of the home. It is documenting an existing IPv6 deployment > > by Swisscom and allows all packets inbound/outbound EXCEPT for some > > layer-4 ports where attacks and vulnerabilities (such as weak > > passwords) are well-known. The policy is a proposed set of rules > > that can be used as a default setting. The set of blocked inbound > > and outbound ports is expected to be updated as threats come and go. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-01 > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-balanced-ipv6-security-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b6d7f7ad998f504ed15387e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Section 2, Threats, still lists 6 threats of whi= ch only one (the fourth) is addressed by the proposed implementation and th= en, only partially.

In my opinion this is very misleading as S= wisscoms customers might get the impression their ISP's approach helps = against the 5 other threats as well, which it doesnot.
I'd delete the section altogether.

Kind re= gards,

Marc


On Fri, Dec 6, 2013 at 4:51 PM, Guillaume Leclanche <guillaume@leclanche.net> wrote:
Hello,

This is a new version of the draft after having analyzed the WGLC
comments and the Security Directorate review.

A lot of text was modified to make sure that the document could not be
mistaken for a recommendation. The filtering concept and examples are
not changed, as the authors have chosen to stick to describing the
documented practice.

There are new mentions of PCP and UPnP, and the Security
Considerations part was also detailed.

Guillaume

2013/12/6 =A0<internet-draft= s@ietf.org>:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =A0This draft is a work item of the IPv6 Operations Working Group of t= he IETF.
>
> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Balanced Security for IPv6= Residential CPE
> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Martin Gysi
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Guillaume Leclanch= e
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Vyncke
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ragnar Anfinsen > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-balanced-ip= v6-security-01.txt
> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9
> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-06
>
> Abstract:
> =A0 =A0This document describes how an IPv6 residential Customer Premis= e
> =A0 =A0Equipment (CPE) can have a balanced security policy that allows= for a
> =A0 =A0mostly end-to-end connectivity while keeping the major threats<= br> > =A0 =A0outside of the home. =A0It is documenting an existing IPv6 depl= oyment
> =A0 =A0by Swisscom and allows all packets inbound/outbound EXCEPT for = some
> =A0 =A0layer-4 ports where attacks and vulnerabilities (such as weak > =A0 =A0passwords) are well-known. =A0The policy is a proposed set of r= ules
> =A0 =A0that can be used as a default setting. =A0The set of blocked in= bound
> =A0 =A0and outbound ports is expected to be updated as threats come an= d go.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iet= f-v6ops-balanced-ipv6-security
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-v6ops-b= alanced-ipv6-security-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-v6ops-balanced-ipv6-security-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b6d7f7ad998f504ed15387e-- From alexandru.petrescu@gmail.com Mon Dec 9 01:13:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F391AD9AD for ; Mon, 9 Dec 2013 01:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4IaGBiMnhcm for ; Mon, 9 Dec 2013 01:13:08 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id C2F041ADEC4 for ; Mon, 9 Dec 2013 01:13:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB99CrnO010884; Mon, 9 Dec 2013 10:12:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AD84B203D34; Mon, 9 Dec 2013 10:13:08 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E3B7203D11; Mon, 9 Dec 2013 10:13:08 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB99CiKX022206; Mon, 9 Dec 2013 10:12:53 +0100 Message-ID: <52A5898C.5020002@gmail.com> Date: Mon, 09 Dec 2013 10:12:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Owen DeLong , "Bernie Volz (volz)" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:13:13 -0000 Le 07/12/2013 03:39, Owen DeLong a écrit : > I see unicast RAs from time to time on my network. Haven't delved too > deeply into whether they come from the Juniper, Mikrotik, Linux, or > all three. The unicast RAs are there probably in response to a preceding NS or RS, which are themselves sometimes multicast, but could also be unicast. Alex > > Sorry, I stopped using $C here years ago because the power and > cooling were getting out of hand compared to what I could do with > much cheaper $M and $J boxes. > > (This is my home network, 2620:0:930::/48. I'm not speaking of or for > $DAYJOB at the moment). > > Is a link-local multicast on WiFi implemented as multiple unicasts > for some reason? If not, then I can't imagine it would be any worse > than ARP. > > Owen > > On Dec 6, 2013, at 18:25 , Bernie Volz (volz) > wrote: > >> Yes, I am aware of that - unicast RA from the router to the client >> is available. Just isn't clear now often it is used. >> >> But, this doesn't address the periodic RAs normally sent by routers >> as those are multicast. >> >> - Bernie >> >> -----Original Message----- From: Owen DeLong >> [mailto:owen@delong.com] Sent: Friday, December 06, 2013 9:07 PM >> To: Bernie Volz (volz) Cc: Mark ZZZ Smith; Andrew Yourtchenko >> (ayourtch); v6ops@ietf.org Subject: Re: [v6ops] New Version >> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt >> (fwd) >> >> >> On Dec 6, 2013, at 17:25 , Bernie Volz (volz) >> wrote: >> >>> Mark: >>> >>> The difference between DHCPv6 and RA multicast is the direction. >>> >>> DHCPv6 multicast is client to server (or relay). This has far >>> fewer problems in some networks because the first hop is >>> typically on the wired portion of the network (and the >>> destination multicast address is usually just joined by a few >>> devices (relays and servers) - not all). >> >> You should study RA a little better. >> >>> >>> RA multicast is router to client(s). This has problems in >>> distributing the traffic out to all of the clients over some >>> networks. >> >> >> Only some RA is done this way. >> >> Clients starting up (and/or a client whose address is close to its >> lifetime) send an RS message to a multicast group joined by only a >> few. There are no "hops" because this is all link-local >> communication. >> >> Routers then respond either with a multicast or a unicast RA. >> >> As such, I think this provides at least the same reliability as >> DHCPv6 per your comments above, while also providing the additional >> robustness you already attributed to all-hosts-multicast periodic >> RAs from the routers. >> >> Owen >> >>> >>> - Bernie >>> >>> -----Original Message----- From: v6ops >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith Sent: >>> Friday, December 06, 2013 8:01 PM To: Andrew Yourtchenko >>> (ayourtch) Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version >>> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>> (fwd) >>> >>> >>> ----- Original Message ----- >>>> From: Andrew Yourtchenko To: Mark ZZZ >>>> Smith Cc: "v6ops@ietf.org" >>>> Sent: Saturday, 7 December 2013 3:34 AM >>>> Subject: Re: [v6ops] New Version Notification for >>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>>> >>>> Hi Mark, >>>> >>>> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: >>>> >>>>> Hi, >>>>> >>>>> Some criticisms/comments/questions on these pieces of text >>>>> relating to >>>> layer 2/wifi multicast reliablity: >>>>> >>>>> "This is where the peer-to-peer, acknowledged nature of >>>>> DHCPv6 may be beneficial - on a crowded large-scale WiFi, >>>>> without special tricks to ensure the reliable delivery of >>>>> multicast packets, you simply will not get the SLAAC working >>>>> because the multicast RAs will get crunched by the >>>>> interference." I'd think that if multicast is unreliable >>>>> enough to cause RAs to fail to be delivered often enough, >>>>> then anything which relies on multicast traffic is also >>>>> likely to fail, which would include neighbor discovery. So >>>>> regardless of if RAs were replaced with DHCPv6, the link is >>>>> not going to provide reliable IPv6 operation, because IPv6 >>>>> addresses cannot be reliably resolved to layer 2 addresses. >>>>> >>>>> MLD would probably fail too, so any routed multicast >>>>> applications, even low bandwidth ones, wouldn't work either, >>>>> as would MLD snooping based layer 2 forwarding >>>>> optimisation. >>>>> >>>>> DHCPv6 uses multicast for DHCPv6 server/relay discovery, so >>>>> that will >>>> probably be unreliable as well. >>>>> >>>>> I don't think broadcasts on wifi are reliable, so IPv4 ARP >>>>> would be >>>> failing too. >>>>> >>>>> So if RAs are failing because of not reliable enough >>>>> multicast then that is just one symptom of the link being >>>>> overloaded, and there will be others. >>>> >>>> I think I capture several points here, tell me if I get them >>>> correctly: >>>> >>>> 1) There are other protocols that use multicast that will >>>> fail. >>> >>> Yes. >>> >>>> 2) Fix your link. >>>> >>>> for (1): RA is probably the only one that does not incorporate >>>> a robust retransmit mechanism. >>>> >>> >>> In the case of multicast RAs there are two independent >>> reliability mechanisms used, one router side, one host side. >>> >>> Firstly, the router lifetime in the RA is to be set to >>> AdvDefaultLifetime or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), >>> meaning that for a host to lose knowledge of a router it has to >>> miss 3 unsolicited multicast RAs in a row. >>> >>> Secondly, hosts retransmit their RSes multiple times (RFC4861, >>> 6.3.7). >>> >>> I'd argue that DHCPv6, neighbor discovery and MLD are less >>> robust, as they only implement the second mechanism. For DHCPv6, >>> neighbor discovery and MLD to be as robust as RAs, the DHCPv6 >>> server and the hosts would have to also issue periodically >>> unsolicited announcements of themselves so that other hosts and >>> routers don't have to solicit for them, unless they have no >>> existing knowledge of them. >>> >>> (Should we add the ES-IS neighbor discovery model to IPv6 ND to >>> make it more robust? ES-IS has hosts periodically multicast their >>> presence to the link's routers, routers periodically multicast >>> their presence to the hosts, hosts default to sending to their >>> routers for all destinations, then routers sends a redirects to a >>> host when the destination host is on the same link.). >>> >>> >>>> for (2): It's great if you can, but I'd like to have protocol >>>> work in all conditions. >>> >>> That sound to me like an assertion that DHCPv6 is going to work >>> in all conditions. Given that DHCPv6 server discovery is less >>> reliable than RAs (because of the lack of unsolicited DHCPv6 >>> server advertisements), how is moving RA functions into DHCPv6 >>> going to make DHCPv6 more reliable than RAs? >>> >>>> Especially that legacy IP does look more robust. >>> >>>> >>> >>> So I'm curious why legacy IP is supposedly more robust? IPv4 uses >>> broadcasts for ARP and DHCP server discovery. On these links >>> where IPv4 "looks more robust" than IPv6, are broadcasts provided >>> more reliable delivery than multicasts, in particular as >>> broadcasts must be flooded to all hosts, where as multicasts can >>> have their flooding scope limited using MLD snooping? >>> >>> >>>> >>>>> One idea I've had for this sort of scenario would be for the >>>>> link to operate as mostly an IPv6 over NBMA segment. The only >>>>> multicasts on the link are RAs, providing the necessary NBMA >>>>> operation parameters. It of course would require changes to >>>>> clients and routers, but then again, so would using DHCPv6 >>>>> for what RAs are used for today. >>>> >>>> You can do this with no changes today. >>>> >>>> Block traffic between the hosts (similar to private vlan), >>>> advertise prefixes as off-link, send all the traffic via the >>>> router on the wired side, block all the inbound ND from hosts >>>> except for the RS and NS sent to solicited node address of the >>>> router + destined to the router. >>>> >>>> I tested this, it works like a charm - at least for the >>>> strawman browsing scenario. >>>> >>> >>> Right, and doing that would solve the multicast capacity >>> exhaustion problems that would effect RA multicasts (and DHCPv6, >>> ND and MLD multicasts), because it is a more extreme case of >>> constraining where multicasts are sent than MLD snooping. >>> >>> My Broadcast Multi-Access (BMA) link operating as NBMA suggestion >>> wouldn't require both having available and enabling any >>> link-layer special features to achieve the goal of significantly >>> reducing multicast traffic. >>> >>> (Thinking about it, the recent Efficient ND proposal is perhaps >>> a special case of operating a BMA link as an NBMA link for the >>> Neighbor Discovery protocol. I'm starting to wonder if it might >>> be better to just adopt this complete NBMA model over a BMA link >>> and eliminate all link-layer multicasts (ND, DHCPv6, MLD), except >>> RAs to announce the BMA link is operating in NBMA mode. The only >>> multicasts would be unsolicited RAs, which, for a single router, >>> could be only once every 30 minutes (15 minutes for two routers). >>> I'd think that sort of interval would be adequate to address the >>> concerns of multicasts consuming mobile device battery life.) >>> >>> >>>>> >>>>> "Alternatively, in a very mobile environment and the >>>>> RFC-compliant >>>>> >>>>> router, multicast solicited RAs might make a significant >>>>> portion of your traffic - which, due to a difference in >>>>> modulation, etc. may eat way more bandwidth than if they >>>>> were sent unicast." >>>>> >>>>> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd think >>>>> if a link can't handle 1 multicast every few seconds, it's >>>>> also past the point >>>> of >>>>> it's capacity (and as above, other multicast/broadcast would >>>>> also be contributing to exceeding link capacity.) >>>> >>>> Modulation. Your multicast packets may take in the most extreme >>>> case 54x time more airtime than a unicast. This means 54x more >>>> probability it will be dropped. Also, forget the home wireless >>>> with one AP. Now imagine 300-500 APs having to send these >>>> packets. You have 3 frequencies on 2.4Ghz spectrum that you can >>>> use. So remembering that the whole construct is 3D, you are >>>> *bound* to have some interference. >>>> >>> >>> Are all of those 300-500 APs in a single broadcast/multicast >>> domain i.e., one large link? That's convenient, but if >>> multicasts/broadcasts aren't reliable enough, that suggests the >>> link capacity is exhausted. Dividing the link up using routers to >>> reduce multicast/broadcasts is and has been the common solution >>> since broadcast multiaccess links were invented (which I think >>> would be since around late 1970s when Ethernet was invented). >>> >>> Moving to an NBMA model by effectively modelling the BMA link as >>> a full mesh of virtual point-to-point links would probably be an >>> alternative method of overcoming multicast/broadcast capacity >>> limitations. >>> >>>> So, it can be quite delicate in the most extreme cases. >>>> >>>> And again, I want the protocol to be deployable in the most >>>> extreme cases - especially when legacy IP survives them fine. >>>> >>> >>> How does it? Legacy IP uses broadcasts. >>> >>>> Yes, not everyone will have them. >>>> >>>> But dismissing those cases just because they do not apply to >>>> one's environment is incorrect. >>>> >>>> And this is to me the whole point of the argument, which I >>>> would like to get back to, instead of trying to argue about the >>>> details: >>>> >>>> Yes, RA-only operation is *fantastic* for some circumstances. I >>>> love it myself and do it whenever I can because this allows me >>>> to avoid doing boring work. >>>> >>>> But I may be forced to do DHCPv6. For any of the reasons >>>> already present in the draft, pick one. And this means I am >>>> forced to do also RA, which is a pain. >>>> >>> >>> So the objections I have are, >>> >>> - I don't see how anything in DHCPv6 makes it dramatically more >>> reliable than RAs, given that it too uses multicasts for DHCPv6 >>> server discovery. Adding RA functions into DHCPv6 is described or >>> asserted to be the panacea to all issues that RAs could suffer >>> from, yet analysis shows it isn't. >>> >>> - I think it would be better to incrementally tune and optimise >>> the existing designed, standardised, code developed, code >>> debugged and widely deployed mechanism (RAs) to overcome corner >>> cases, and/or to adopt past developed methods such as IPv6 over >>> NBMA, than to spend the next 5 to 10 years waiting for the >>> design, standardisation, code development, code debugging and >>> widespread deployment of RA functions to be incorporated into >>> DHCPv6, and then also have to develop methods of conflict >>> resolution when RAs and DHCPv6 options disagree (because they >>> will, unless you don't plan to transition to DHCPv6 only until >>> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions >>> will have to co-exist on a link for many years if you can't >>> demand or guarantee DHCPv6 RA functionality from the host >>> implementations.) >>> >>> - Using DHCPv6 for RA functionality won't eliminate one of the >>> supposed causes of RA unreliability - multicast unreliability. >>> All of DHCPv6, neighbor discovery and MLD would have to be made >>> more robust against multicast unreliability to truly solve that >>> problem. >>> >>> - I'm for a single method that works adequately. DHCPv6 with RA >>> options would probably qualify if we didn't already have a >>> existing method. Existing methods that work are always better >>> than non-existent ones that need to be developed, tested and >>> ubiquitously deployed before they become significantly useful and >>> can be assumed to be available. >>> >>> >>>> I think the large part of the tussle comes from the people >>>> wanting to make the functionality of the RA/DHCPv6 more >>>> symmetric and being told "no". >>>> >>> >>> The thing they need to demonstrate is that the costs of deploying >>> a new and second mechanism that is near functionally equivalent >>> to the first is worth the benefits. Given that the costs of >>> developing and deploying RAs has already been paid, I think the >>> benefits of using DHCPv6 for RA functions have to be very >>> significant before the price should be paid. The benefits of >>> DHCPv6 for RA functions now needs to be compelling. I don't think >>> they are, otherwise I'd be quite happy to advocate for DHCPv6 for >>> RA functions. >>> >>> >>>> And if we then tell them "Either use RA or no IPv6 for you" >>>> they say >>> >>>> "fine, I choose no IPv6". And keep stacking on these NATs to >>>> support devices that "do not support IPv6" in that >>>> circumstances. >>>> >>> >>> I don't think RAs are the single reason some people are resisting >>> deploying IPv6 at all. I think some people are resisting >>> deploying IPv6 because it needs to do one or both of two things >>> for them - solve a foreseeable problem that will effect them, or >>> provide a tangible benefit. If it won't do either of those >>> things, then they don't currently see any value from the effort >>> involved. What are foreseeable problems or tangible benefits is >>> completely up to the perspective of the decision maker. >>> Eventually they'll see value in it, and deploy it. In some cases, >>> some people who could deploy IPv6 may never see any value in >>> deploying it, so they never will. >>> >>> There is no single answer to why people might resist deploying >>> IPv6, no single solution, and things that motivate people to >>> deploy or not IPv6 may have nothing to do with how IPv6 itself >>> works. >>> >>> >>> >>>> I think in this discussion are again getting into the argument >>>> of "the best solution" instead of trying to collect the >>>> properties of the RA and DHCP. >>>> >>>> My position is that single best solution does not exist, >>>> because >>> >>>> everyone's problems are slightly different. So, rather than >>>> preaching for everyone to adopt the single solution which is >>>> the best in one scenario and suboptimal in the other, we should >>>> be engineering a way to be able to apply different solutions in >>>> different circumstances without the overhead of double work. >>>> >>> >>> A single solution that solves most cases is better than two >>> different, near functionally equivalent solutions that solve the >>> same cases. Multiple near-equivalent solutions create more code, >>> more bugs and then require conflict resolution mechanisms, >>> creating even more code and more bugs, with very little actual >>> benefit. >>> >>> There are multiple ways of solving the neighbor discovery/router >>> discovery/host parameter configuration problem (read Radia >>> Perlman's "Interconnections" book as a starting point, and then >>> perhaps "Inside Appletalk", and also look into Novell's IPX and >>> Network Directory Services.). They all have different trade-offs, >>> but fundamentally the trade-offs aren't significantly different >>> or compelling. Yet because there are multiple methods to solve >>> these problems, does that justify implementing all of them >>> because they each have some minor benefits over the others, that >>> different people might prefer? >>> >>> Regards, Mark. _______________________________________________ >>> v6ops mailing list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Mon Dec 9 01:15:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AB31AE251 for ; Mon, 9 Dec 2013 01:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h7mXvN0iIai for ; Mon, 9 Dec 2013 01:15:21 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4991AE225 for ; Mon, 9 Dec 2013 01:15:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB99FD5J032257; Mon, 9 Dec 2013 10:15:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 24141203B83; Mon, 9 Dec 2013 10:15:28 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 168D2203D5B; Mon, 9 Dec 2013 10:15:28 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB99FCau024637; Mon, 9 Dec 2013 10:15:13 +0100 Message-ID: <52A58A21.5090109@gmail.com> Date: Mon, 09 Dec 2013 10:15:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andrew Yourtchenko , Mark ZZZ Smith References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:15:25 -0000 Le 07/12/2013 20:56, Andrew Yourtchenko a écrit : > On Fri, 6 Dec 2013, Mark ZZZ Smith wrote: > > [snip] > >> >> So the objections I have are, >> >> - I don't see how anything in DHCPv6 makes it dramatically more >> reliable than RAs, given that it too uses multicasts for DHCPv6 server >> discovery. Adding RA functions into DHCPv6 is described or asserted to >> be the panacea to all issues that RAs could suffer from, yet analysis >> shows it isn't. > > Adding RA functions to DHCP allows to get rid of RAs for the scenarios > where you have to run DHCP, plain and simple. > >> >> - I think it would be better to incrementally tune and optimise the >> existing designed, standardised, code developed, code debugged and >> widely deployed mechanism (RAs) to overcome corner cases, and/or to >> adopt past developed methods such as IPv6 over NBMA, than to spend the >> next 5 to 10 years waiting for the design, standardisation, code >> development, code debugging and widespread deployment of RA functions >> to be incorporated into DHCPv6, and then also have to develop methods >> of conflict resolution when RAs and DHCPv6 options disagree (because >> they will, unless you don't plan to transition to DHCPv6 only until >> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions will >> have to co-exist on a link for many years if you can't demand or >> guarantee DHCPv6 RA functionality from the host implementations.) > > Conflict resolution is simple: fix your network. You are describing as a > problem what isn't. > > The http://xkcd.com/927/ is indeed a problem. But, this is a question of > engineering, and using that as a blanket argument against DHCP-only > operation is incorrect. > >> >> - Using DHCPv6 for RA functionality won't eliminate one of the >> supposed causes of RA unreliability - multicast unreliability. All of >> DHCPv6, neighbor discovery and MLD would have to be made more robust >> against multicast unreliability to truly solve that problem. > > Gee, we are stuck on the strawman ureliability - there are *other* > reasons why one would want to use DHCP, thus being forced to run > multiple protocols. > >> >> - I'm for a single method that works adequately. DHCPv6 with RA >> options would probably qualify if we didn't already have a existing >> method. Existing methods that work are always better than non-existent >> ones that need to be developed, tested and ubiquitously deployed >> before they become significantly useful and can be assumed to be >> available. >> >> >>> I think the large part of the tussle comes from the people wanting to >>> make the functionality of the RA/DHCPv6 more symmetric and being told >>> "no". >>> >> >> The thing they need to demonstrate is that the costs of deploying a >> new and second mechanism that is near functionally equivalent to the >> first is worth the benefits. Given that the costs of developing and >> deploying RAs has already been paid, I think the benefits of using >> DHCPv6 for RA functions have to be very significant before the price >> should be paid. The benefits of DHCPv6 for RA functions now needs to >> be compelling. I don't think they are, otherwise I'd be quite happy to >> advocate for DHCPv6 for RA functions. > > For some, the benefit would be significant. For some - it won't be any > benefit at all. I agree. This is a good double point that deserves being mentioned. Alex > >> >> >>> And if we then tell them "Either use RA or no IPv6 for you" they say >> >>> "fine, I choose no IPv6". And keep stacking on these NATs to support >>> devices that "do not support IPv6" in that circumstances. >>> >> >> I don't think RAs are the single reason some people are resisting >> deploying IPv6 at all. I think some people are resisting deploying >> IPv6 because it needs to do one or both of two things for them - solve >> a foreseeable problem that will effect them, or provide a tangible >> benefit. If it won't do either of those things, then they don't >> currently see any value from the effort involved. What are foreseeable >> problems or tangible benefits is completely up to the perspective of >> the decision maker. Eventually they'll see value in it, and deploy it. >> In some cases, some people who could deploy IPv6 may never see any >> value in deploying it, so they never will. > > It's not binary. You can represent as a number both the amount of pain > that a given problem (or set of problems) causes, and the amount of pain > that the big change in the network like adding a new protocol causes. > > As soon as the first number is smaller than the second one, nothing gets > done. > > Judging by the feedback I get from talking with people, even the > possibility of eventually eliminating RAs from their network might make > the second number smaller for a nontrivial amount folks, whose situation > dictates the DHCPv6. > >> >> There is no single answer to why people might resist deploying IPv6, >> no single solution, and things that motivate people to deploy or not >> IPv6 may have nothing to do with how IPv6 itself works. >> >> >> >>> I think in this discussion are again getting into the argument of >>> "the best solution" instead of trying to collect the properties of >>> the RA and DHCP. >>> >>> My position is that single best solution does not exist, because >> >>> everyone's problems are slightly different. So, rather than preaching >>> for everyone to adopt the single solution which is the best in one >>> scenario and suboptimal in the other, we should be engineering a way >>> to be able to apply different solutions in different circumstances >>> without the overhead of double work. >>> >> >> A single solution that solves most cases is better than two different, > > That's the point. The single solution that solves most cases, does not > exist. For a good part of the cases, you need to apply two solutions at > once. Justifiably, the question is "why", given in legacy IP they did > not need to do that. > > --a > >> near functionally equivalent solutions that solve the same cases. >> Multiple near-equivalent solutions create more code, more bugs and >> then require conflict resolution mechanisms, creating even more code >> and more bugs, with very little actual benefit. >> >> There are multiple ways of solving the neighbor discovery/router >> discovery/host parameter configuration problem (read Radia Perlman's >> "Interconnections" book as a starting point, and then perhaps "Inside >> Appletalk", and also look into Novell's IPX and Network Directory >> Services.). They all have different trade-offs, but fundamentally the >> trade-offs aren't significantly different or compelling. Yet because >> there are multiple methods to solve these problems, does that justify >> implementing all of them because they each have some minor benefits >> over the others, that different people might prefer? > >> >> Regards, >> Mark. >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Mon Dec 9 01:16:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DE01AD9AD for ; Mon, 9 Dec 2013 01:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y7bKQBWx0o5 for ; Mon, 9 Dec 2013 01:16:39 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id DC4C01AE25B for ; Mon, 9 Dec 2013 01:16:31 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rB99GDXm012536; Mon, 9 Dec 2013 10:16:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0FE6A203D4A; Mon, 9 Dec 2013 10:16:28 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01B2B203D11; Mon, 9 Dec 2013 10:16:28 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rB99GCHF025764; Mon, 9 Dec 2013 10:16:13 +0100 Message-ID: <52A58A5D.2020205@gmail.com> Date: Mon, 09 Dec 2013 10:16:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Owen DeLong , Mark ZZZ Smith References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6DDF@xmb-rcd-x04.cisco.com> <96ACE7B5-C7D3-4C77-BEFE-561B525C0B75@delong.com> <489D13FBFA9B3E41812EA89F188F018E1ADD6F4B@xmb-rcd-x04.cisco.com> <1386385836.88691.YahooMailNeo@web161906.mail.bf1.yahoo.com> <2B3AF247-B5CB-4A4A-878E-B9C17983CBC6@delong.com> In-Reply-To: <2B3AF247-B5CB-4A4A-878E-B9C17983CBC6@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:16:43 -0000 Le 07/12/2013 22:05, Owen DeLong a écrit : > I don't see a need for or benefit from doing so. I think unicast RAs > should only be sent in response to RS. > > I do see a valid use case for hosts sending RS if they are getting > close to their desired or valid timers. Or if they are getting close (as in geographical vicinity) to a Router that they know it must be there... Alex > > Owen > > On Dec 6, 2013, at 19:10 , Mark ZZZ Smith > wrote: > >> >> >> >> >> ----- Original Message ----- >>> From: Bernie Volz (volz) To: Owen DeLong >>> Cc: Mark ZZZ Smith ; >>> Andrew Yourtchenko (ayourtch) ; >>> "v6ops@ietf.org" Sent: Saturday, 7 December 2013 >>> 1:25 PM Subject: RE: [v6ops] New Version Notification for >>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>> >>> Yes, I am aware of that - unicast RA from the router to the >>> client is available. Just isn't clear now often it is used. >>> >>> But, this doesn't address the periodic RAs normally sent by >>> routers as those are multicast. >>> >> >> As a router would have knowledge of the hosts it has sent unicast >> RAs to via its neighbor cache, for the purposes of NUD, a router >> could periodically unicast RAs directly to the individual hosts. >> >> >> Regards, Mark. >> >> >>> - Bernie >>> >>> >>> -----Original Message----- From: Owen DeLong >>> [mailto:owen@delong.com] Sent: Friday, December 06, 2013 9:07 PM >>> To: Bernie Volz (volz) Cc: Mark ZZZ Smith; Andrew Yourtchenko >>> (ayourtch); v6ops@ietf.org Subject: Re: [v6ops] New Version >>> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>> (fwd) >>> >>> >>> On Dec 6, 2013, at 17:25 , Bernie Volz (volz) >>> wrote: >>> >>>> Mark: >>>> >>>> The difference between DHCPv6 and RA multicast is the >>>> direction. >>>> >>>> DHCPv6 multicast is client to server (or relay). This has far >>>> fewer >>> problems in some networks because the first hop is typically on >>> the wired portion of the network (and the destination multicast >>> address is usually just joined by a few devices (relays and >>> servers) - not all). >>> >>> You should study RA a little better. >>> >>>> >>>> RA multicast is router to client(s). This has problems in >>>> distributing the >>> traffic out to all of the clients over some networks. >>> >>> >>> Only some RA is done this way. >>> >>> Clients starting up (and/or a client whose address is close to >>> its lifetime) send an RS message to a multicast group joined by >>> only a few. There are no "hops" because this is all link-local >>> communication. >>> >>> Routers then respond either with a multicast or a unicast RA. >>> >>> As such, I think this provides at least the same reliability as >>> DHCPv6 per your comments above, while also providing the >>> additional robustness you already attributed to >>> all-hosts-multicast periodic RAs from the routers. >>> >>> Owen >>> >>>> >>>> - Bernie >>>> >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith >>>> Sent: Friday, December 06, 2013 8:01 PM To: Andrew Yourtchenko >>>> (ayourtch) Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version >>>> Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt >>>> (fwd) >>>> >>>> >>>> ----- Original Message ----- >>>>> From: Andrew Yourtchenko To: Mark ZZZ >>>>> Smith Cc: "v6ops@ietf.org" >>>>> Sent: Saturday, 7 December 2013 3:34 AM >>>>> Subject: Re: [v6ops] New Version Notification for >>>>> draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>>>> >>>>> Hi Mark, >>>>> >>>>> On Thu, 5 Dec 2013, Mark ZZZ Smith wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Some criticisms/comments/questions on these pieces of text >>>>>> relating to >>>>> layer 2/wifi multicast reliablity: >>>>>> >>>>>> "This is where the peer-to-peer, acknowledged nature of >>> DHCPv6 may >>>>>> be beneficial - on a crowded large-scale WiFi, without >>>>>> special >>> tricks >>>>>> to ensure the reliable delivery of multicast packets, you >>>>>> simply will not get the SLAAC working because the >>>>>> multicast RAs will get crunched by the interference." I'd >>>>>> think that if multicast is unreliable enough to cause RAs >>> to >>>>>> fail to be delivered often enough, then anything which >>>>>> relies on multicast traffic is also likely to fail, which >>>>>> would include >>> neighbor discovery. >>>>>> So regardless of if RAs were replaced with DHCPv6, the link >>>>>> is not going to provide reliable IPv6 operation, because >>>>>> IPv6 addresses cannot be reliably resolved to layer 2 >>>>>> addresses. >>>>>> >>>>>> MLD would probably fail too, so any routed multicast >>> applications, >>>>>> even low bandwidth ones, wouldn't work either, as would >>>>>> MLD snooping based layer 2 forwarding optimisation. >>>>>> >>>>>> DHCPv6 uses multicast for DHCPv6 server/relay discovery, so >>>>>> that will >>>>> probably be unreliable as well. >>>>>> >>>>>> I don't think broadcasts on wifi are reliable, so IPv4 ARP >>> would >>>>>> be >>>>> failing too. >>>>>> >>>>>> So if RAs are failing because of not reliable enough >>>>>> multicast then that is just one symptom of the link being >>>>>> overloaded, and there will be others. >>>>> >>>>> I think I capture several points here, tell me if I get them >>>>> correctly: >>>>> >>>>> 1) There are other protocols that use multicast that will >>>>> fail. >>>> >>>> Yes. >>>> >>>>> 2) Fix your link. >>>>> >>>>> for (1): RA is probably the only one that does not >>>>> incorporate a robust retransmit mechanism. >>>>> >>>> >>>> In the case of multicast RAs there are two independent >>>> reliability >>> mechanisms used, one router side, one host side. >>>> >>>> Firstly, the router lifetime in the RA is to be set to >>>> AdvDefaultLifetime >>> or 3 * MaxRtrAdvInterval (RFC4861, 6.2.1), meaning that for a >>> host to lose knowledge of a router it has to miss 3 unsolicited >>> multicast RAs in a row. >>>> >>>> Secondly, hosts retransmit their RSes multiple times (RFC4861, >>>> 6.3.7). >>>> >>>> I'd argue that DHCPv6, neighbor discovery and MLD are less >>>> robust, as >>> they only implement the second mechanism. For DHCPv6, neighbor >>> discovery and MLD to be as robust as RAs, the DHCPv6 server and >>> the hosts would have to also issue periodically unsolicited >>> announcements of themselves so that other hosts and routers don't >>> have to solicit for them, unless they have no existing knowledge >>> of them. >>>> >>>> (Should we add the ES-IS neighbor discovery model to IPv6 ND to >>>> make it >>> more robust? ES-IS has hosts periodically multicast their >>> presence to the link's routers, routers periodically multicast >>> their presence to the hosts, hosts default to sending to their >>> routers for all destinations, then routers sends a redirects to a >>> host when the destination host is on the same link.). >>>> >>>> >>>>> for (2): It's great if you can, but I'd like to have >>>>> protocol >>> work in >>>>> all conditions. >>>> >>>> That sound to me like an assertion that DHCPv6 is going to work >>>> in all >>> conditions. Given that DHCPv6 server discovery is less reliable >>> than RAs (because of the lack of unsolicited DHCPv6 server >>> advertisements), how is moving RA functions into DHCPv6 going to >>> make DHCPv6 more reliable than RAs? >>>> >>>>> Especially that legacy IP does look more robust. >>>> >>>>> >>>> >>>> So I'm curious why legacy IP is supposedly more robust? IPv4 >>>> uses >>> broadcasts for ARP and DHCP server discovery. On these links >>> where IPv4 "looks more robust" than IPv6, are broadcasts provided >>> more reliable delivery than multicasts, in particular as >>> broadcasts must be flooded to all hosts, where as multicasts can >>> have their flooding scope limited using MLD snooping? >>>> >>>> >>>>> >>>>>> One idea I've had for this sort of scenario would be for >>>>>> the >>> link >>>>>> to operate as mostly an IPv6 over NBMA segment. The only >>>>>> multicasts >>> >>>>>> on the link are RAs, providing the necessary NBMA >>>>>> operation >>> parameters. >>>>>> It of course would require changes to clients and routers, >>>>>> but >>> then >>>>>> again, so would using DHCPv6 for what RAs are used for >>>>>> today. >>>>> >>>>> You can do this with no changes today. >>>>> >>>>> Block traffic between the hosts (similar to private vlan), >>>>> advertise prefixes as off-link, send all the traffic via the >>>>> router on the wired side, block all the inbound ND from hosts >>>>> except for the RS and NS sent to solicited node address of >>>>> the router + destined to the >>> router. >>>>> >>>>> I tested this, it works like a charm - at least for the >>>>> strawman browsing scenario. >>>>> >>>> >>>> Right, and doing that would solve the multicast capacity >>>> exhaustion >>> problems that would effect RA multicasts (and DHCPv6, ND and MLD >>> multicasts), because it is a more extreme case of constraining >>> where multicasts are sent than MLD snooping. >>>> >>>> My Broadcast Multi-Access (BMA) link operating as NBMA >>>> suggestion >>> wouldn't require both having available and enabling any >>> link-layer special features to achieve the goal of significantly >>> reducing multicast traffic. >>>> >>>> (Thinking about it, the recent Efficient ND proposal is perhaps >>>> a special case of operating a BMA link as an NBMA link for the >>>> Neighbor Discovery protocol. I'm starting to wonder if it might >>>> be better to just adopt this complete NBMA model over a BMA >>>> link and eliminate all link-layer multicasts (ND, DHCPv6, MLD), >>>> except RAs to announce the BMA link is operating in NBMA mode. >>>> The only multicasts would be unsolicited RAs, which, for a >>>> single router, could be only once every 30 minutes (15 minutes >>>> for two routers). I'd think that sort of interval would be >>>> adequate to address the concerns of multicasts consuming mobile >>>> device battery life.) >>>> >>>> >>>>>> >>>>>> "Alternatively, in a very mobile environment and the >>> RFC-compliant >>>>>> >>>>>> router, multicast solicited RAs might make a significant >>>>>> portion >>> of >>>>>> your traffic - which, due to a difference in modulation, >>>>>> etc. >>> may >>>>>> eat way more bandwidth than if they were sent unicast." >>>>>> >>>>>> The MIN_DELAY_BETWEEN_RAS in RFC4861 is 3 seconds. I'd >>>>>> think >>> if a >>>>>> link can't handle 1 multicast every few seconds, it's >>>>>> also >>> past the >>>>>> point >>>>> of >>>>>> it's capacity (and as above, other multicast/broadcast >>>>>> would >>> also be >>>>>> contributing to exceeding link capacity.) >>>>> >>>>> Modulation. Your multicast packets may take in the most >>>>> extreme case 54x time more airtime than a unicast. This means >>>>> 54x more probability it will be dropped. Also, forget the >>>>> home wireless with one AP. Now imagine 300-500 APs having to >>>>> send these packets. You have 3 frequencies on 2.4Ghz spectrum >>>>> that you can use. So remembering that the whole construct is >>>>> 3D, you are *bound* to have some interference. >>>>> >>>> >>>> Are all of those 300-500 APs in a single broadcast/multicast >>>> domain i.e., >>> one large link? That's convenient, but if multicasts/broadcasts >>> aren't reliable enough, that suggests the link capacity is >>> exhausted. Dividing the link up using routers to reduce >>> multicast/broadcasts is and has been the common solution since >>> broadcast multiaccess links were invented (which I think would >>> be since around late 1970s when Ethernet was invented). >>>> >>>> Moving to an NBMA model by effectively modelling the BMA link >>>> as a full >>> mesh of virtual point-to-point links would probably be an >>> alternative method of overcoming multicast/broadcast capacity >>> limitations. >>>> >>>>> So, it can be quite delicate in the most extreme cases. >>>>> >>>>> And again, I want the protocol to be deployable in the most >>>>> extreme cases - especially when legacy IP survives them >>>>> fine. >>>>> >>>> >>>> How does it? Legacy IP uses broadcasts. >>>> >>>>> Yes, not everyone will have them. >>>>> >>>>> But dismissing those cases just because they do not apply to >>>>> one's environment is incorrect. >>>>> >>>>> And this is to me the whole point of the argument, which I >>>>> would like to get back to, instead of trying to argue about >>>>> the details: >>>>> >>>>> Yes, RA-only operation is *fantastic* for some circumstances. >>>>> I love it myself and do it whenever I can because this allows >>>>> me to avoid doing boring work. >>>>> >>>>> But I may be forced to do DHCPv6. For any of the reasons >>>>> already present in the draft, pick one. And this means I am >>>>> forced to do also RA, which is a pain. >>>>> >>>> >>>> So the objections I have are, >>>> >>>> - I don't see how anything in DHCPv6 makes it dramatically >>>> more >>> reliable than RAs, given that it too uses multicasts for DHCPv6 >>> server discovery. Adding RA functions into DHCPv6 is described or >>> asserted to be the panacea to all issues that RAs could suffer >>> from, yet analysis shows it isn't. >>>> >>>> - I think it would be better to incrementally tune and optimise >>>> the existing designed, standardised, code developed, code >>>> debugged and widely deployed mechanism (RAs) to overcome corner >>>> cases, and/or to adopt past developed methods such as IPv6 over >>>> NBMA, than to spend the next 5 to 10 years waiting for the >>>> design, standardisation, code development, code debugging and >>>> widespread deployment of RA functions to be incorporated into >>>> DHCPv6, and then also have to develop methods of conflict >>>> resolution when RAs and DHCPv6 options disagree (because they >>>> will, unless you don't plan to transition to DHCPv6 only until >>>> DHCPv6 RA functions are ubiquitous. RAs and DHCPv6 RA functions >>>> will have to co-exist on a link for many years if you can't >>>> demand or guarantee DHCPv6 RA functionality from the host >>>> implementations.) >>>> >>>> - Using DHCPv6 for RA functionality won't eliminate one of the >>>> supposed >>> causes of RA unreliability - multicast unreliability. All of >>> DHCPv6, neighbor discovery and MLD would have to be made more >>> robust against multicast unreliability to truly solve that >>> problem. >>>> >>>> - I'm for a single method that works adequately. DHCPv6 with RA >>>> options >>> would probably qualify if we didn't already have a existing >>> method. Existing methods that work are always better than >>> non-existent ones that need to be developed, tested and >>> ubiquitously deployed before they become significantly useful and >>> can be assumed to be available. >>>> >>>> >>>>> I think the large part of the tussle comes from the people >>>>> wanting to make the functionality of the RA/DHCPv6 more >>>>> symmetric and being told "no". >>>>> >>>> >>>> The thing they need to demonstrate is that the costs of >>>> deploying a new and >>> second mechanism that is near functionally equivalent to the >>> first is worth the benefits. Given that the costs of developing >>> and deploying RAs has already been paid, I think the benefits of >>> using DHCPv6 for RA functions have to be very significant before >>> the price should be paid. The benefits of DHCPv6 for RA functions >>> now needs to be compelling. I don't think they are, otherwise I'd >>> be quite happy to advocate for DHCPv6 for RA functions. >>>> >>>> >>>>> And if we then tell them "Either use RA or no IPv6 for you" >>> they say >>>> >>>>> "fine, I choose no IPv6". And keep stacking on these NATs to >>> support >>>>> devices that "do not support IPv6" in that circumstances. >>>>> >>>> >>>> I don't think RAs are the single reason some people are >>>> resisting >>> deploying IPv6 at all. I think some people are resisting >>> deploying IPv6 because it needs to do one or both of two things >>> for them - solve a foreseeable problem that will effect them, or >>> provide a tangible benefit. If it won't do either of those >>> things, then they don't currently see any value from the effort >>> involved. What are foreseeable problems or tangible benefits is >>> completely up to the perspective of the decision maker. >>> Eventually they'll see value in it, and deploy it. In some cases, >>> some people who could deploy IPv6 may never see any value in >>> deploying it, so they never will. >>>> >>>> There is no single answer to why people might resist deploying >>>> IPv6, no >>> single solution, and things that motivate people to deploy or not >>> IPv6 may have nothing to do with how IPv6 itself works. >>>> >>>> >>>> >>>>> I think in this discussion are again getting into the >>>>> argument of "the best solution" instead of trying to collect >>>>> the >>> properties of >>>>> the RA and DHCP. >>>>> >>>>> My position is that single best solution does not exist, >>>>> because >>>> >>>>> everyone's problems are slightly different. So, rather than >>> preaching >>>>> for everyone to adopt the single solution which is the best >>>>> in one scenario and suboptimal in the other, we should be >>>>> engineering a way to be able to apply different solutions in >>>>> different circumstances without the overhead of double work. >>>>> >>>> >>>> A single solution that solves most cases is better than two >>>> different, near >>> functionally equivalent solutions that solve the same cases. >>> Multiple near-equivalent solutions create more code, more bugs >>> and then require conflict resolution mechanisms, creating even >>> more code and more bugs, with very little actual benefit. >>>> >>>> There are multiple ways of solving the neighbor >>>> discovery/router >>> discovery/host parameter configuration problem (read Radia >>> Perlman's "Interconnections" book as a starting point, and then >>> perhaps "Inside Appletalk", and also look into Novell's IPX and >>> Network Directory Services.). They all have different trade-offs, >>> but fundamentally the trade-offs aren't significantly different >>> or compelling. Yet because there are multiple methods to solve >>> these problems, does that justify implementing all of them >>> because they each have some minor benefits over the others, that >>> different people might prefer? >>>> >>>> Regards, Mark. _______________________________________________ >>>> v6ops mailing list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From markzzzsmith@yahoo.com.au Mon Dec 9 02:41:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4661AE269 for ; Mon, 9 Dec 2013 02:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmzi21trnxpg for ; Mon, 9 Dec 2013 02:41:30 -0800 (PST) Received: from nm33.bullet.mail.bf1.yahoo.com (nm33.bullet.mail.bf1.yahoo.com [72.30.238.133]) by ietfa.amsl.com (Postfix) with SMTP id 308051AE156 for ; Mon, 9 Dec 2013 02:41:30 -0800 (PST) Received: from [98.139.212.149] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 09 Dec 2013 10:41:25 -0000 Received: from [98.139.212.197] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 09 Dec 2013 10:41:25 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 09 Dec 2013 10:41:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 161860.71866.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 27411 invoked by uid 60001); 9 Dec 2013 10:41:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1386585685; bh=1kJyGCQB5+DdZHxbIsKBbcNb+E8D0Y/98Bfvz8M4CMQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Cfkpbi3zh9CRaCTpEWbwyQGZmTcXbMOk/7eX2wPimZKvQJ/uTuCkYJdHfJzC+zcgXNHTz6zjugN6NOw5rRS2rM+7Q1d7kNM5RPIRdJg3iTciRUKCQIUML0hoC/qDfAx8C8QlJhd4gIoedLCY2gLjp50vLVwjaULfwl0tvPNUP7o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=c6flblf0F9cBuK3SX4aYGok4uu/PpzrHQyPQj+wreo+yClhzRTiFR5Y0gweLGeE/PBgH0fEKEDrTrFrwyRYjIVdymGY5dZjNnoW1OSIRHcQJdfpIcXje66sXmICa1iGQkrHqv6gSA0QJPtpmhsbP5gdvuoEDWxvF/sXGtpkQqU4=; X-YMail-OSG: mSMNOa4VM1mOMP07LcwSNWoClJOd9sG3CLrpNokp84n_.U2 NwfokMVR33yRGyH9nKG6ekL4ia9SNXsxtwTF5uyZIoYESb21haDih6ON4yKO f5RyQcaZML_yuxAeNAuGfLPFngzdQY9eqtDm05FvXN_e.2Gu78pp5dHTY3hv dWIqTGcsWWIX9uYfy1q4t2T2AbLAIxvWYq2JnDyoDtkflemyvVqONl3Cdv4u e6iZWprtiWUBo5mLI.UipsdxOA25jkIW.dUJsTEYJqY2Tj6EAujczBvtD0aM fRiRTVkDHFLaIL4ILr6w8Pjk3sX2XC05jmKJJaFKebh9SpFLmTKsEAXTzaYI XikDqZSG3Iev2t9g8On7BFcveKzdb3Z1OO3341nMwXFx6dv3VUsuVwLpKjyO IjkEN.pf1T63DfYHh90JuEPNUTUL5xXsirEdsjrsaUlAkVmXyUT1nqs5BTuj ca0m5kIexcvPJ6jHXxeXcW_D80iRofCOw4j8hZZsf1b7aS7_jZvQM3170HVX comP5CaKnmHGGbs19EWM1mSbiHhYzBJlfCm605PQEac0D9KbF9avypmK8Hnu MDUErr95Ast8N Received: from [150.101.221.237] by web161906.mail.bf1.yahoo.com via HTTP; Mon, 09 Dec 2013 02:41:24 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.VG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PiAKPkNjOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT47IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20.OyAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBNb25kYXksIDkgRGVjZW1iZXIgMjAxMyA0OjIwIFBNCj5TdWJqZWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> <22BFD8E2-4406-46A8-93F2-702319C32344@delong.com> Message-ID: <1386585684.5001.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Mon, 9 Dec 2013 02:41:24 -0800 (PST) From: Mark ZZZ Smith To: Owen DeLong In-Reply-To: <22BFD8E2-4406-46A8-93F2-702319C32344@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:41:31 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Owen DeLong =0A>To: Mark ZZZ Smith =0A>Cc: And= rew Yourtchenko ; Bernie Volz (volz) ; = "v6ops@ietf.org" =0A>Sent: Monday, 9 December 2013 4:20 PM= =0A>Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-= dhcpv6-comparison-00.txt (fwd)=0A> =0A>=0A>=0A>Technical people like choice= and flexibility, because I think they think about "what ifs" - "what if I = was in this situation, what if I was in that situation, and what would I li= ke to tweak to make it work." Non-technical end-users (usually our customer= s or at least our relatives), who far surpass us in numbers, don't care, sh= ouldn't care and shouldn't have to care. They just want it to work, work re= liably, and don't want to have to engage technical people to either make it= work or call in assistance if it doesn't work or stops working. Choices, o= ptions and parameters make things more complex and therefore more fragile a= nd less robust.=0A>>=0A>=0A>I don=E2=80=99t mind the flipper door, but I re= ally hate it when people remove all the knobs. (The non-technical users sho= uldn=E2=80=99t open the flipper door).=0A>=0A=0A=0AThe knobs are still ther= e, they're called static configuration.=0A=0A>=0A>We currently have a singl= e mechanism to announce a default gateway, and the default gateway announce= s itself, out of the box. That makes it pretty hard, if not impossible for = that information to be wrong.=C2=A0DHCPv6 for default gateways would in the= DHCPv6 relay scenario would require human entry of that information, creat= ing the opportunity for human error, and potential conflict with what RAs a= re announcing.=0A>>=0A>=0A>It=E2=80=99s not hard at all. All you have to do= is put a router on the network that is connected away from, instead of tow= ards the internet and voila, you have arguably =E2=80=9Cwrong=E2=80=9D RAs.= =0A>=0A=0AIf I understand your scenario, the RAs are right, it is the route= table in the router that is broken (or rather, the upstream network is par= titioned). I don't see how putting default router information in DHCPv6 is = going to prevent the same problem, or lessen the effects of it. Chances are= it might increase the likelihood of issues, because it is one more thing f= or humans to get wrong when they enter it into their DHCPv6 server.=0A=0AHo= wever, this discussion is only about how hosts learn their default gateway/= router information, not whether once the packets make it to the router they= can be forwarded by the routing domain to their destination successfully.= =0A=0A>=0A>This won=E2=80=99t usually break anything because redirects usua= lly work and even if they don=E2=80=99t, you just put unnecessary load on t= he network and the router that can=E2=80=99t forward the packets. However, = if that router doesn=E2=80=99t know the correct address for the other route= rs, then your RAs will be truly wrong and things do break.=0A>=0A=0AThere a= re a few ways of resolving this.=0A=0AFirstly, the routers on the link coul= d be trading routing information using e.g, OSPF via the link the hosts are= attached to if that is the only way the two separate upstream networks are= interconnected.=0A=0ASecondly, one of the routers could have a High RA pre= ference (RFC4191), and then that router has static routes towards the prefi= xes behind the other routers. Having the other routers continue to announce= lower preference RAs means that if the High preference router fails, hosts= still have a level of reachability to the prefixes behind the remaining ro= uters.=0A=0AFinally, some level of routing information could be pushed to t= he hosts so they pick the correct first hop router. RAs support providing t= his information via the Route Information Option (RFC4191).=0A=0AThere are = VRRP options too, however I've limited the above to what can just be done w= ith RAs.=0A=0ARegards,=0AMark. From owen@delong.com Mon Dec 9 06:52:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677A41AE305 for ; Mon, 9 Dec 2013 06:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzpO-j9hMeI6 for ; Mon, 9 Dec 2013 06:52:25 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B919A1AE2FC for ; Mon, 9 Dec 2013 06:52:24 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rB9En2Cc031836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Dec 2013 06:49:03 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rB9En2Cc031836 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386600544; bh=7P5zTq1qffMOSF9gZZ8Qpm+omxk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ZW7ZE33fA/IJOLJg2mOAspnsd+lpv+HS5RgvVTdNk1J8WbX5WIRswA8r+T6WonXRo HyUrRm1v2Phd8/bz16cJhvN3jdqzo7MFbGbkks7GNRpsYeyjeMtH+Js3No5kpydQkU ShUdyFkCnhA/7ZvZE9HjwI1me3sn9SjTY4U58Kcg= Content-Type: multipart/alternative; boundary="Apple-Mail=_6B7EE679-966D-4962-A456-CAD308A10F3A" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <1386585684.5001.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Mon, 9 Dec 2013 06:49:10 -0800 Message-Id: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> <22BFD8E2-4406-46A8-93F2-702319C32344@delong.com> <1386585684.5001.YahooMailNeo@web161906.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 09 Dec 2013 06:49:04 -0800 (PST) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:52:28 -0000 --Apple-Mail=_6B7EE679-966D-4962-A456-CAD308A10F3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 9, 2013, at 2:41 AM, Mark ZZZ Smith = wrote: >=20 >=20 >=20 >=20 >=20 >> ________________________________ >> From: Owen DeLong >> To: Mark ZZZ Smith =20 >> Cc: Andrew Yourtchenko ; Bernie Volz (volz) = ; "v6ops@ietf.org" =20 >> Sent: Monday, 9 December 2013 4:20 PM >> Subject: Re: [v6ops] New Version Notification for = draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) >>=20 >>=20 >>=20 >> Technical people like choice and flexibility, because I think they = think about "what ifs" - "what if I was in this situation, what if I was = in that situation, and what would I like to tweak to make it work." = Non-technical end-users (usually our customers or at least our = relatives), who far surpass us in numbers, don't care, shouldn't care = and shouldn't have to care. They just want it to work, work reliably, = and don't want to have to engage technical people to either make it work = or call in assistance if it doesn't work or stops working. Choices, = options and parameters make things more complex and therefore more = fragile and less robust. >>>=20 >>=20 >> I don=92t mind the flipper door, but I really hate it when people = remove all the knobs. (The non-technical users shouldn=92t open the = flipper door). >>=20 >=20 >=20 > The knobs are still there, they're called static configuration. I didn=92t mean to imply that the knobs weren=92t there. Indeed, RAs = have a very large number of knobs for such a lightweight protocol and = DHCPv6 has even more. >=20 >>=20 >> We currently have a single mechanism to announce a default gateway, = and the default gateway announces itself, out of the box. That makes it = pretty hard, if not impossible for that information to be wrong. DHCPv6 = for default gateways would in the DHCPv6 relay scenario would require = human entry of that information, creating the opportunity for human = error, and potential conflict with what RAs are announcing. >>>=20 >>=20 >> It=92s not hard at all. All you have to do is put a router on the = network that is connected away from, instead of towards the internet and = voila, you have arguably =93wrong=94 RAs. >>=20 >=20 > If I understand your scenario, the RAs are right, it is the route = table in the router that is broken (or rather, the upstream network is = partitioned). I don't see how putting default router information in = DHCPv6 is going to prevent the same problem, or lessen the effects of = it. Chances are it might increase the likelihood of issues, because it = is one more thing for humans to get wrong when they enter it into their = DHCPv6 server. >=20 No, the route table in the router is not broken, it just doesn=92t have = a default route to the upstream routers. There are a number of = situations where this could even be desirable (for example, the systems = on the back-end network behind this third router are not supposed to = send/receive from networks beyond the LAN in question). I=92m not saying that it does. I=92m saying that RAs from routers don=92t = necessarily guarantee that the routers are telling the truth. Not all = routers are valid default route candidates. However, the current IPv6 implementations seem to assume that they are. The point is that while RA can be easier and more reliably accurate than = routing information from DHCPv6 in many scenarios, this is not = necessarily always true. Adding the equivalent of RIOs to DHCPv6 would = be harmless to those who wish to use only RAs while allowing operators = to choose the solution that works best for them. > However, this discussion is only about how hosts learn their default = gateway/router information, not whether once the packets make it to the = router they can be forwarded by the routing domain to their destination = successfully. Yes, but if hosts are learning default routers that aren=92t good = candidates for that function, one could make the argument that such a = scenario is not desirable. >=20 >>=20 >> This won=92t usually break anything because redirects usually work = and even if they don=92t, you just put unnecessary load on the network = and the router that can=92t forward the packets. However, if that router = doesn=92t know the correct address for the other routers, then your RAs = will be truly wrong and things do break. >>=20 >=20 > There are a few ways of resolving this. >=20 > Firstly, the routers on the link could be trading routing information = using e.g, OSPF via the link the hosts are attached to if that is the = only way the two separate upstream networks are interconnected. Which results in the redirects and hair pinning described in my = paragraph you are claiming this solution resolves. > Secondly, one of the routers could have a High RA preference = (RFC4191), and then that router has static routes towards the prefixes = behind the other routers. Having the other routers continue to announce = lower preference RAs means that if the High preference router fails, = hosts still have a level of reachability to the prefixes behind the = remaining routers. Which takes you back to fiddling knobs and the potential for human error = in the configuration process. > Finally, some level of routing information could be pushed to the = hosts so they pick the correct first hop router. RAs support providing = this information via the Route Information Option (RFC4191). Which also requires fiddling the knobs and re-inserting the potential = for human error. > There are VRRP options too, however I've limited the above to what can = just be done with RAs. I wasn=92t trying to put this forward as an insurmountable problem. I = was just pointing out that RAs are not a panacea solution to all = possible problems associated with routing information from DHCP. Owen --Apple-Mail=_6B7EE679-966D-4962-A456-CAD308A10F3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 9, 2013, at 2:41 AM, Mark ZZZ = Smith <markzzzsmith@yahoo.com.au>= ; wrote:






________________________________
From: Owen DeLong = <owen@delong.com>
To: = Mark ZZZ Smith <markzzzsmith@yahoo.com.au>= ; 
Cc: Andrew = Yourtchenko <ayourtch@cisco.com>; Bernie = Volz (volz) <volz@cisco.com>; = "v6ops@ietf.org" <v6ops@ietf.org> 
Sent: Monday, 9 = December 2013 4:20 PM
Subject: Re: [v6ops] New Version Notification = for draft-yourtchenko-ra-dhcpv6-comparison-00.txt = (fwd)



Technical people like choice and flexibility, = because I think they think about "what ifs" - "what if I was in this = situation, what if I was in that situation, and what would I like to = tweak to make it work." Non-technical end-users (usually our customers = or at least our relatives), who far surpass us in numbers, don't care, = shouldn't care and shouldn't have to care. They just want it to work, = work reliably, and don't want to have to engage technical people to = either make it work or call in assistance if it doesn't work or stops = working. Choices, options and parameters make things more complex and = therefore more fragile and less robust.


I don=92t mind the flipper door, but = I really hate it when people remove all the knobs. (The non-technical = users shouldn=92t open the flipper = door).



The knobs are still there, they're = called static configuration.

I = didn=92t mean to imply that the knobs weren=92t there. Indeed, RAs have = a very large number of knobs for such a lightweight protocol and DHCPv6 = has even more.




We = currently have a single mechanism to announce a default gateway, and the = default gateway announces itself, out of the box. That makes it pretty = hard, if not impossible for that information to be wrong. DHCPv6 = for default gateways would in the DHCPv6 relay scenario would require = human entry of that information, creating the opportunity for human = error, and potential conflict with what RAs are = announcing.


It=92s not = hard at all. All you have to do is put a router on the network that is = connected away from, instead of towards the internet and voila, you have = arguably =93wrong=94 RAs.


If I understand your = scenario, the RAs are right, it is the route table in the router that is = broken (or rather, the upstream network is partitioned). I don't see how = putting default router information in DHCPv6 is going to prevent the = same problem, or lessen the effects of it. Chances are it might increase = the likelihood of issues, because it is one more thing for humans to get = wrong when they enter it into their DHCPv6 = server.


No, the route = table in the router is not broken, it just doesn=92t have a default = route to the upstream routers. There are a number of situations where = this could even be desirable (for example, the systems on the back-end = network behind this third router are not supposed to send/receive = from
networks beyond the LAN in = question).

I=92m not saying that it does. I=92m = saying that RAs from routers don=92t necessarily guarantee that the = routers are telling the truth. Not all routers are valid default route = candidates.

However, the current IPv6 = implementations seem to assume that they = are.

The point is that while RA can be easier = and more reliably accurate than routing information from DHCPv6 in many = scenarios, this is not necessarily always true. Adding the equivalent of = RIOs to DHCPv6 would be harmless to those who wish to use only RAs while = allowing operators to choose the solution that works best for = them.

However, this discussion is only about how hosts learn their = default gateway/router information, not whether once the packets make it = to the router they can be forwarded by the routing domain to their = destination successfully.

Yes, but = if hosts are learning default routers that aren=92t good candidates for = that function, one could make the argument that such a scenario is not = desirable.



This = won=92t usually break anything because redirects usually work and even = if they don=92t, you just put unnecessary load on the network and the = router that can=92t forward the packets. However, if that router doesn=92t= know the correct address for the other routers, then your RAs will be = truly wrong and things do break.


There are a few = ways of resolving this.

Firstly, the routers on the link could be = trading routing information using e.g, OSPF via the link the hosts are = attached to if that is the only way the two separate upstream networks = are interconnected.

Which results = in the redirects and hair pinning described in my paragraph you are = claiming this solution resolves.

Secondly, one of the routers could = have a High RA preference (RFC4191), and then that router has static = routes towards the prefixes behind the other routers. Having the other = routers continue to announce lower preference RAs means that if the High = preference router fails, hosts still have a level of reachability to the = prefixes behind the remaining = routers.

Which takes you back to = fiddling knobs and the potential for human error in the configuration = process.

Finally, some level of routing information could be pushed to the = hosts so they pick the correct first hop router. RAs support providing = this information via the Route Information Option = (RFC4191).

Which also requires = fiddling the knobs and re-inserting the potential for human = error.

There = are VRRP options too, however I've limited the above to what can just be = done with RAs.

I wasn=92t = trying to put this forward as an insurmountable problem. I was just = pointing out that RAs are not a panacea solution to all possible = problems associated with routing information from = DHCP.

Owen

= --Apple-Mail=_6B7EE679-966D-4962-A456-CAD308A10F3A-- From Fred.L.Templin@boeing.com Mon Dec 9 08:00:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AEC1AE35F for ; Mon, 9 Dec 2013 08:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4MdFzOt_z_X for ; Mon, 9 Dec 2013 08:00:11 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id D0A671AE35B for ; Mon, 9 Dec 2013 08:00:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id rB9G01YC007991; Mon, 9 Dec 2013 08:00:02 -0800 Received: from XCH-PHX-412.sw.nos.boeing.com (xch-phx-412.sw.nos.boeing.com [10.57.37.44]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rB9FxteV007716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 9 Dec 2013 07:59:55 -0800 Received: from XCH-BLV-201.nw.nos.boeing.com (10.57.37.66) by XCH-PHX-412.sw.nos.boeing.com (10.57.37.44) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 07:59:54 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-BLV-201.nw.nos.boeing.com ([169.254.1.197]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 07:59:54 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO9FDsQnO15PgAhUO5WOfzcFr2DZpL2h4AgABZxQCAAEU6AP//i+zg Date: Mon, 9 Dec 2013 15:59:54 +0000 Message-ID: <2134F8430051B64F815C691A62D98318172C99@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <489D13FBFA9B3E41812EA89F188F018E1ADD7D60@xmb-rcd-x04.cisco.com> <1386533152.79592.YahooMailNeo@web161905.mail.bf1.yahoo.com> <22BFD8E2-4406-46A8-93F2-702319C32344@delong.com> <1386585684.5001.YahooMailNeo@web161906.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:00:13 -0000 Hi, all RAs on ISATAP links are unicast and, in spite of my best efforts to bring it into the specs the operation of DHCPv6 over ISATAP links is undefined. And, as I said several days ago, unicast RAs can deliver different information to different clients. Thanks - Fred fred.l.templin@boeing.com From sarikaya2012@gmail.com Mon Dec 9 08:34:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B3C1AE328 for ; Mon, 9 Dec 2013 08:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YEqI5aPUEwl for ; Mon, 9 Dec 2013 08:34:53 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id ABE341ADFC8 for ; Mon, 9 Dec 2013 08:34:52 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id b8so1787676lan.13 for ; Mon, 09 Dec 2013 08:34:47 -0800 (PST) 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=im/VWTnh9S6OgsoX0MhAL577iwfN0t/h4PHHXFb+rA0=; b=I+IFd8m+sRSZ+QlqN/RbngpgRKuiaN+KwW381npNlhDm0xnlxI2OFUH3TCPGojtwJx 6jsAqT7u/oRDQ+wQNWnr1XgZaTbPusBJYUzUDXg5p34bLQVsRRSr+/5ntYM6FB4AD8Rv vZCS24SmN1k2aiqYGF36uscouvMNlMSATBZ/dv4tVuOCP+UxuicgZQFX5/ARboRhHP8O Qrr4S7Gd0zI6vbD+fIzC/88KqQJf1M29QQdT/EfVOB7GsF+REyniTtg9WR1m8Rybeveu t3aMohaAm9nhQMK8fzPn3TFm4dElM9hyykJfllH5FQVJOXhXwR1DLBB3UxTwo/Jki5T/ BabA== MIME-Version: 1.0 X-Received: by 10.152.21.74 with SMTP id t10mr2403534lae.65.1386606887021; Mon, 09 Dec 2013 08:34:47 -0800 (PST) Received: by 10.115.4.165 with HTTP; Mon, 9 Dec 2013 08:34:46 -0800 (PST) In-Reply-To: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> Date: Mon, 9 Dec 2013 10:34:46 -0600 Message-ID: From: Behcet Sarikaya To: Fred Baker Content-Type: multipart/alternative; boundary=089e01494164f1b23c04ed1c9239 Cc: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:34:54 -0000 --089e01494164f1b23c04ed1c9239 Content-Type: text/plain; charset=ISO-8859-1 Hi authors, I think this draft is requirements draft while draft-yourtchenko-ra-dhcpv6-comparison-00.txt is problem statement draft for the same issue. My suggestion is requirements on delivering routes to the hosts also should be added to this draft. Regards, Behcet On Wed, Dec 4, 2013 at 7:45 AM, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Please > take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e01494164f1b23c04ed1c9239 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi authors,

I think this = draft is requirements draft while draft-yourtchenko-ra-dhcpv6-comparison-00.txt is problem statement draf= t for the same issue.

My suggestion= is requirements on delivering routes to the hosts also should be added to = this draft.

Regards,

Behcet


On = Wed, Dec 4, 2013 at 7:45 AM, <fred@cisco.com> wrote:

A new draft has been posted, at http://tools.ietf.org/h= tml/draft-ietf-v6ops-dhcpv6-slaac-problem. Please take a look at it and= comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--089e01494164f1b23c04ed1c9239-- From simon.perreault@viagenie.ca Mon Dec 9 12:39:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27741AE555 for ; Mon, 9 Dec 2013 12:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb957h2A-ox3 for ; Mon, 9 Dec 2013 12:39:24 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 998041AE554 for ; Mon, 9 Dec 2013 12:39:24 -0800 (PST) Received: from balaise.nomis80.org (unknown [IPv6:2620:0:230:2001::100d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7B7E4400A8 for ; Mon, 9 Dec 2013 15:39:19 -0500 (EST) Message-ID: <52A62A77.7050307@viagenie.ca> Date: Mon, 09 Dec 2013 15:39:19 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> <595EE489-CA27-4D98-ACB1-3E8F8E79B54D@cisco.com> <044CE3AE-81CE-40DD-8E70-B6A067F4E9E5@cisco.com> In-Reply-To: <044CE3AE-81CE-40DD-8E70-B6A067F4E9E5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:39:26 -0000 Le 06/12/2013 17:33, Fred Baker (fred) a écrit : > Using Swisscom's experience as an > example of the working group's outcome is fine, but then the document > has to reflect the working group's viewpoint. Swisscom can be an > example, but not the controlling interest. Let's try to untie this knot... Guillaume initially wrote: "The filtering concept and examples are not changed, as the authors have chosen to stick to describing the documented practice." I understood this meant that the editors had interpreted WG consensus to be that they should not change the draft, not that they themselves decided to ignore WG consensus. Indeed, the WGLC generated a lot of discussion and I guess it was hard to extract clear guidance. In those cases, status quo looks attractive from an editor's viewpoint. That hints at what is needed now: clear guidance on what the WG consensus actually is. (Just as a WG participant closely following this draft since the beginning, and eager to see where it will go...) Simon From otroan@employees.org Mon Dec 9 14:02:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989751AE5D2; Mon, 9 Dec 2013 14:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdX6LbJXHJP1; Mon, 9 Dec 2013 14:02:15 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id DFE531AE57C; Mon, 9 Dec 2013 14:02:14 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANc8plKQ/khN/2dsb2JhbABZgwe6IYEzFnSCJQEBBAF5EAtGVwaIDwbAcxePEAeDIIETA5AxmXaDKjs X-IronPort-AV: E=Sophos;i="4.93,860,1378857600"; d="asc'?scan'208";a="1928348" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 09 Dec 2013 22:02:09 +0000 Received: from dhcp-10-61-107-180.cisco.com (dhcp-10-61-107-180.cisco.com [10.61.107.180]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB9M24Al011101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 22:02:05 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_D967E5EA-30E8-401F-B57A-D58D98FF2474"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Mon, 9 Dec 2013 23:02:03 +0100 Message-Id: <06F520D6-675B-4E38-909F-7D33E76C6B53@employees.org> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> To: Sander Steffann X-Mailer: Apple Mail (2.1822) Cc: V6 Ops List , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:02:16 -0000 --Apple-Mail=_D967E5EA-30E8-401F-B57A-D58D98FF2474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> Not sure I should sent this one to DHCPv6 WG or the global IETF v6, = so feel free to forward it if needed. this is a product of the v6ops working group, so probably the discussion = belongs there. >> Last week, RFC7084 got posted. I did already post a message on a = rather badly phrased req (a SHOULD one regarding =93long-enough=94, but = bumped into the next one today (this one being a lot worse!!). >>=20 >> =93=94 >> WAA-6: If the IPv6 CE router receives a Router Advertisement >> message (described in [RFC4861]) with the M flag set to 1, >> the IPv6 CE router MUST do DHCPv6 address assignment >> (request an IA_NA option). >> =93=94 >> I=92m not sure who came up with this one, but this is really a no-go. >> So, according to this req, the DHCPv6 client must request an ia_na = option if an M=3D1 is being received on his link ??? I might have = understood it all wrong, but as far as I know, M=3D1 is not linked = directly to ia_na, ia_pd is enough on its own, no ?? >=20 > Actually the other way around: M=3D1 is linked to ia_na but not to = ia_pd. A CPE always does ia_pd, regardless of the M flag, but the ia_na = is only requested when M=3D1. the text is written so that there does not have to be any binding = between RA processing and the DHCP state machine. a CPE can simply ignore the O/M flags, and always request an IA_NA. >> So, the CPE is expected to change its DHCPv6 client configuration = based upon receiving an RA with this M=3D1 content ? >=20 > Yep, that's the meaning :-) or it can ignore it, see above. >> I=92m very curious on the replies now, but this seems really be going = the wrong way. You can launch a CPE which either listen to RA or not, = and bound accordingly, however, listen + bind + force ia_na looks a bit = too much to me. >=20 > You always have to listen to RA, otherwise you won't have your default = gateway. If you don't want a global address on the CPE WAN link = (assuming that A=3D0 in the prefix option, but it doesn't have to be) = you could ignore the M=3D1 flag and not do ia_na. cheers, Ole --Apple-Mail=_D967E5EA-30E8-401F-B57A-D58D98FF2474 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSpj3cAAoJEFuJXizso86gccsIAJ0uVFFsfZQDHpeNl0xF7wJ7 I2vNsFKZjbGtGQCJ0GNsSSaBEtMD17fK7HUaSG5CIj5M8oyj7tNxHBZ4GqP1ks86 mJuyHMUFBB1ViKnZ8xy+dZoiVd/FR+T+pfJcD33kidHEpoUY5yft/yjTJkzMnqAd 0eIttjOTh8QG33HR8yvGhJArJF3TxSYrKod1E0oZPs4HL/oyIdFlvrmXR1qs2zgI SekmSx+/SYteWSQ01EolP+Kd5bXCV2eZMg91kusp7X++zsRJWYjr+voTpXHo0VVb TVbXc1XWs8+VmhwfNQFH2aiudXHgWJu06zFNMh+F5lxTJl5OSK4iRZMm4Ga5cl4= =MaSz -----END PGP SIGNATURE----- --Apple-Mail=_D967E5EA-30E8-401F-B57A-D58D98FF2474-- From sander@steffann.nl Mon Dec 9 14:14:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2CB1AE124; Mon, 9 Dec 2013 14:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LccqSBvttqyb; Mon, 9 Dec 2013 14:14:20 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2C45B1AE119; Mon, 9 Dec 2013 14:14:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0BE1F51; Mon, 9 Dec 2013 23:14:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgzIidwF1d+i; Mon, 9 Dec 2013 23:14:12 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 7F32634; Mon, 9 Dec 2013 23:14:12 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Sander Steffann In-Reply-To: <06F520D6-675B-4E38-909F-7D33E76C6B53@employees.org> Date: Mon, 9 Dec 2013 23:14:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <06F520D6-675B-4E38-909F-7D33E76C6B53@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1822) Cc: V6 Ops List , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:14:21 -0000 Hi, Op 9 dec. 2013, om 23:02 heeft Ole Troan het = volgende geschreven: >> Actually the other way around: M=3D1 is linked to ia_na but not to = ia_pd. A CPE always does ia_pd, regardless of the M flag, but the ia_na = is only requested when M=3D1. >=20 > the text is written so that there does not have to be any binding = between RA processing and the DHCP state machine. > a CPE can simply ignore the O/M flags, and always request an IA_NA. Ah, good to know. I always interpreted the M flag as 'there is a = stateful DHCPv6 server available'. I never really though about doing = IA_NA when M=3D0, but I guess the client is always free to try :-) Thanks, Sander From Carl.Wuyts@technicolor.com Mon Dec 9 22:55:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECE81AE2CF; Mon, 9 Dec 2013 22:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRxCxYUECTTO; Mon, 9 Dec 2013 22:55:29 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4161AD9B7; Mon, 9 Dec 2013 22:55:24 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUqa62FbEjq9N6PACPfYtNQ/xlXLYt60v@postini.com; Mon, 09 Dec 2013 22:55:21 PST Received: from MOPESMAILHTC02.eu.thmulti.com (141.11.100.178) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 10 Dec 2013 07:55:16 +0100 Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.32]) by MOPESMAILHTC02.eu.thmulti.com ([141.11.100.178]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 07:55:17 +0100 From: Wuyts Carl To: "STARK, BARBARA H" , "" Thread-Topic: RFC7084 Thread-Index: Ac705Oox+bAOGgDPSBCf3B3p1FF6cAAA4TqgACKmQYA= Date: Tue, 10 Dec 2013 06:55:16 +0000 Message-ID: <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [141.11.249.10] Content-Type: multipart/related; boundary="_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 06:55:35 -0000 --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: multipart/alternative; boundary="_000_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_" --_000_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry Barbara, But I still don't agree. I read below: "" If the access network does not set M=3D1, it cannot be sure the CE router w= ill request IA_NA. If it does set M=3D1, it *can* be sure the RFC7084-compl= iant CE router will request IA_NA. "" Again, you're binding WRONG the M to ia_na. this is really not good. Let = us implement standards based upon what they are designed for. The M-flag w= as initially designed to flag the device to be Managed, not to be "numbered= " flag, in this case, make it N=3D1! If we keep bending all kind of rules f= or the sake of access networks, or whatever other reason, then let's just s= top making standards completely, as they serve no goal. If today one reads= IPv6 RFCs, (s)he will never map M=3D1 to ia_na request or not, and this is= how it should be. So, why not just ask all options all together then ? the access network ca= n cope, and no matter what you ask, something will be served !! Stop pleasing setting these silly requirements. The "if prefix is too smal= l" req was already very badly phrased, but this is a lot worse. I hear on congresses that "the CPE router" is often a problem in v6 deploym= ent, although not that much anymore recently, but please consider it as a m= ature device in the network, not let it bending all kind of rules for whate= ver sake. Standards are defined for a reason, so let's all stick to it please, and no= t "tweaking" them for whatever reason. If you want the CPE to ask ia_na, f= ine with me, but then create the statement to ask for it ALL the time, not = just because of M=3D1 setting. Please note we merely operate in a managed CPE-environment, so know upfront= whether ia_na is needed or not, but you here state that the access network= is dictating the M=3D1 to be translated by ANY CPE router as" ask ia_na. = this can only be handled by vendors by ALWAYS asking ia_na I'm afraid. Pl= ease stop glueing things together which are not serving any real goal. Kee= p it simple. If you always want ia_na, fine with me, but make a req to jus= t ask ia_na rather than to bind it to the wrong flag. Just FYI. A lot of our customers don't even use ia_na. And yes, they are = using M=3D1, nearly all of them. Regs Carl From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: maandag 9 december 2013 16:02 To: Wuyts Carl; Subject: RE: RFC7084 RFC7084-compliant CE routers are defined to work in an environment where th= e access network makes the rules. RFC7084-compliant CE routers, by definiti= on of the scope of that RFC, must be able to operate in the access networks= defined by CableLabs and BBF, at the very least. These CE routers don't ge= t to make the rules. The supported-for-interoperability access networks inc= lude ones that require IA_NA for proper operation. They also include ones t= hat do "unnumbered" model and use only IA_PD. They even include access netw= orks that support SLAAC + IA_PD (with no IA_NA). An RFC7084-compliant CE ro= uter will automatically work in all of these access networks, with no speci= al configuration. This was a core goal of the requirements in RFC7084. If an access network is designed to require CE routers to acquire IA_NA, th= en that CE router needs to acquire the IA_NA in order to function on that a= ccess network. This is not negotiable, and is not something the CE router c= an "choose" not to do because it doesn't feel like it. It was agreed that a= n access network that expects IA_NA to be requested will signal this by alw= ays setting M=3D1 in its RA messages. If the access network does not set M= =3D1, it cannot be sure the CE router will request IA_NA. If it does set M= =3D1, it *can* be sure the RFC7084-compliant CE router will request IA_NA. What was agreed, was that CE routers MUST request IA_NA if M=3D1 in the RA.= You are completely correct in your reading of the requirement. If the acce= ss network is designed so that IA_PD is enough, then it will not supply IA_= NA in response to the CE router's request. Such access networks have no dif= ficulty in not providing IA_NA. If the access network is designed to requi= re IA_NA, then it will supply the IA_NA in its response. Since nothing prev= ents the CE router from always requesting IA_NA, anyway, the access network= has to be resilient in the presence of such requests. The CE router is abl= e to work properly in both types of access networks. There is nothing in the description of the "M" bit in RFC 4861 that would f= orbid designing an IPv6 host to always request IA_NA whenever it sees M=3D1= . Therefore, this does not go against RFC 4861. Barbara From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Wuyts Carl Sent: Monday, December 09, 2013 9:02 AM To: > Subject: RFC7084 All, Not sure I should sent this one to DHCPv6 WG or the global IETF v6, so feel= free to forward it if needed. Last week, RFC7084 got posted. I did already post a message on a rather ba= dly phrased req (a SHOULD one regarding "long-enough", but bumped into the = next one today (this one being a lot worse!!). "" WAA-6: If the IPv6 CE router receives a Router Advertisement message (described in [RFC4861]) with the M flag set to 1, the IPv6 CE router MUST do DHCPv6 address assignment (request an IA_NA option). "" I'm not sure who came up with this one, but this is really a no-go. So, according to this req, the DHCPv6 client must request an ia_na option i= f an M=3D1 is being received on his link ??? I might have understood it al= l wrong, but as far as I know, M=3D1 is not linked directly to ia_na, ia_pd= is enough on its own, no ?? So, the CPE is expected to change its DHCPv6 = client configuration based upon receiving an RA with this M=3D1 content ? Extract from RFC4861: "" M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol "" I'm very curious on the replies now, but this seems really be going the wro= ng way. You can launch a CPE which either listen to RA or not, and bound a= ccordingly, however, listen + bind + force ia_na looks a bit too much to me= . regs Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [Visit technicolor.com] [Visit i-speak-qeo.com= ] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium www.technicolor.com - www.i-speak-qeo.com [Follow Technicolor on Facebook]Facebook [Follow Technicolor on Twitter]Twitter [Follow Technicolor on YouTube]YouTube [Follow Technicolor on LinkedIn]LinkedIn Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [Eco] Help preserve the color of our world - Think before you print. --_000_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry Barbara,

 

But I s= till don’t agree.

I read = below:

“= ”

If the access network does not = set M=3D1, it cannot be sure the CE router will request IA_NA. If it does s= et M=3D1, it *can* be sure the RFC7084-compliant CE router will requ= est IA_NA.

“”

Again, = you’re binding WRONG the M to ia_na.  this is really not good.&n= bsp; Let us implement standards based upon what they are designed for. = ; The M-flag was initially designed to flag the device to be Managed, not to be “numbered” flag, in this case, make it N=3D= 1! If we keep bending all kind of rules for the sake of access networks, or= whatever other reason, then let’s just stop making standards complet= ely, as they serve no goal.  If today one reads IPv6 RFCs, (s)he will never map M=3D1 to ia_na request or not, and this is how = it should be.

So, why= not just ask all options all together then ?  the access network can = cope, and no matter what you ask, something will be served !!

&n= bsp;

Stop pl= easing setting these silly requirements.  The “if prefix is too = small” req was already very badly phrased, but this is a lot worse.

I hear = on congresses that “the CPE router” is often a problem in v6 de= ployment, although not that much anymore recently, but please consider it a= s a mature device in the network, not let it bending all kind of rules for whatever sake.

Standar= ds are defined for a reason, so let’s all stick to it please, and not= “tweaking” them for whatever reason.  If you want the CPE= to ask ia_na, fine with me, but then create the statement to ask for it ALL the time, not just because of M=3D1 setting.

&n= bsp;

Please = note we merely operate in a managed CPE-environment, so know upfront whethe= r ia_na is needed or not, but you here state that the access network is dic= tating the M=3D1 to be translated by ANY CPE router as” ask ia_na.   this can only be handled by ve= ndors by ALWAYS asking ia_na I’m afraid.  Please stop glueing th= ings together which are not serving any real goal.  Keep it simple.&nb= sp; If you always want ia_na, fine with me, but make a req to just ask ia_na rather than to bind it to the wrong flag.

&n= bsp;

Just FY= I.  A lot of our customers don’t even use ia_na.  And yes, = they are using M=3D1, nearly all of them.

&n= bsp;

Regs

Carl

&n= bsp;

&n= bsp;

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of STARK, BARBARA H
Sent: maandag 9 december 2013 16:02
To: Wuyts Carl; <ipv6@ietf.org>
Subject: RE: RFC7084

 

RFC7084-compliant CE routers ar= e defined to work in an environment where the access network makes the rule= s. RFC7084-compliant CE routers, by definition of the scope of that RFC, mu= st be able to operate in the access networks defined by CableLabs and BBF, at the very least. These CE routers= don’t get to make the rules. The supported-for-interoperability acce= ss networks include ones that require IA_NA for proper operation. They also= include ones that do “unnumbered” model and use only IA_PD. They even include access networks that support SLAAC &= #43; IA_PD (with no IA_NA). An RFC7084-compliant CE router will automatical= ly work in all of these access networks, with no special configuration. Thi= s was a core goal of the requirements in RFC7084.

 

If an access network is designe= d to require CE routers to acquire IA_NA, then that CE router needs to acqu= ire the IA_NA in order to function on that access network. This is not nego= tiable, and is not something the CE router can “choose” not to do because it doesn’t feel li= ke it. It was agreed that an access network that expects IA_NA to be reques= ted will signal this by always setting M=3D1 in its RA messages. If the acc= ess network does not set M=3D1, it cannot be sure the CE router will request IA_NA. If it does set M=3D1, it *can* be sur= e the RFC7084-compliant CE router will request IA_NA.

 

What was agreed, was that CE ro= uters MUST request IA_NA if M=3D1 in the RA. You are completely correct in = your reading of the requirement. If the access network is designed so that = IA_PD is enough, then it will not supply IA_NA in response to the CE router’s request. Such access networks h= ave no difficulty in not providing IA_NA.  If the access network is de= signed to require IA_NA, then it will supply the IA_NA in its response. Sin= ce nothing prevents the CE router from always requesting IA_NA, anyway, the access network has to be resilient in the pr= esence of such requests. The CE router is able to work properly in both typ= es of access networks.

 

There is nothing in the descrip= tion of the “M” bit in RFC 4861 that would forbid designing an = IPv6 host to always request IA_NA whenever it sees M=3D1. Therefore, this d= oes not go against RFC 4861.

Barbara

&n= bsp;

&n= bsp;

From: ipv6 [mailto= :ipv6-bounces@ietf.org] On Behalf Of Wuyts Carl
Sent: Monday, December 09, 2013 9:02 AM
To: <ipv6@ietf.org>
Subject: RFC7084

 

All,

 

Not sure I should sent this one= to DHCPv6 WG or the global IETF v6, so feel free to forward it if needed.<= o:p>

 

Last week, RFC7084 got posted.&= nbsp; I did already post a message on a rather badly phrased req (a SHOULD = one regarding “long-enough”, but bumped into the next one today= (this one being a lot worse!!).

 

“”

WA= A-6:   If the IPv6 CE router receives a Router Advertisement=

&n= bsp;           message (d= escribed in [RFC4861]) with the M flag set to 1,

&n= bsp;           the IPv6 C= E router MUST do DHCPv6 address assignment

&n= bsp;           (request a= n IA_NA option).

“”

I’m not sure who came up = with this one, but this is really a no-go.

So, according to this req, the = DHCPv6 client must request an ia_na option if an M=3D1 is being received on= his link ???  I might have understood it all wrong, but as far as I k= now, M=3D1 is not linked directly to ia_na, ia_pd is enough on its own, no ??  So, the CPE is expected to change its DH= CPv6 client configuration based upon receiving an RA with this M=3D1 conten= t ?

Extract from RFC4861:

“”

M           &nbs= p;  1-bit "Managed address configuration" flag.  When

            = ;         set, it indicates that ad= dresses are available via

            &nbs= p;        Dynamic Host= Configuration Protocol

 

“”

 

 

I’m very curious on the r= eplies now, but this seems really be going the wrong way.  You can lau= nch a CPE which either listen to RA or not, and bound accordingly, however,= listen + bind + force ia_na looks a bit too much to me.

 

regs 

Carl Wuyts

GCD System Architect Ne= tworking

c= arl.wuyts@technicolor.com

tel.: +32 3 443 65 = 90

3D"Visit 3D"Visit

Prins Boudewijnlaan 47&= nbsp; -  2650 Edegem  -  Belgium

www.technicolor.com - www.i-speak-qeo.com

3D"FollowFacebook<= /span>

3D"FollowTwitter<= /a>

3D"FollowYouTube

Lin= kedIn

Technicolor Delivery Tech= nologies Belgium NV

Registered office (maatsc= happelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium<= /span>

Company registration numb= er (ondernemingsnummer): 0428837295 - RPR Antwerpen

3D"Eco"

Help preserve the = color of our world - Think before you print.

 

 

--_000_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_-- --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1834; creation-date="Tue, 10 Dec 2013 06:55:16 GMT"; modification-date="Tue, 10 Dec 2013 06:55:16 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2740; creation-date="Tue, 10 Dec 2013 06:55:16 GMT"; modification-date="Tue, 10 Dec 2013 06:55:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEAYABgAAD/wAARCABFAFYDAREAAhEBAxEB/9sAhAAGBAUGBQQGBgUGBwcG CAoRCwoJCQoVDxAMERkWGhoYFhgXGx8oIRsdJR4XGCIvIyUpKiwtLBshMTQwKzQoKywrAQcHBwoJ ChQLCxQrHBgcHCsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr Kyv/xAGiAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgsQAAIBAwMCBAMFBQQEAAABfQECAwAE EQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZH SElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1 tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+gEAAwEBAQEBAQEBAQAA AAAAAAECAwQFBgcICQoLEQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGh scEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlq c3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APqmgAoAKACgAoAKACgAoAKACgAo ASR1jRnc4VRkn0FNK7shSkoq7OOPxJ8OZ/4+Jz/2xavT/sjE9l954P8ArNgP5n9wf8LJ8O/897j/ AL8NS/sjE9l94f6zYD+Z/cH/AAsjw7/z3uP+/DUf2Riey+8P9ZcB3f3B/wALJ8O/895/+/LUf2Ri ey+8P9ZsB/M/uD/hZPh3/nvP/wB+Gp/2Riey+8X+s2A/mf3B/wALJ8O/895/+/DUf2Riey+8P9Zs B/M/uD/hZPh3/nvP/wB+Go/sjE9l94f6zYD+Z/cH/CyfDv8Az3n/AO/DUf2Riey+8P8AWbAfzP7i az+IOgXd3DbRTzeZK4Rd0LAZJwKieVYmEXJrReZrS4hwVWahGTu3bY6yvOPbK9//AMeFz/1zb+VX T+NeplX/AIcvRnzCOlffH42dPpPhdG01NT12+TTbCT/Vbl3SS/7q+ledWxrU/ZUY80lv2R7eFymL pKvip8kHt3foi3BoXhnU3FvpWuTRXbcIt5FtWQ+mRjFZyxWLpLmqU9PJm8Mvy7EPkoVmpf3lozmd W0660m/ls76IxzIeR2I7EHuK76NaFWCnDY8XFYWrhqrpVFZop1sc1gouFgouFgoCxoeHv+Q/pn/X 1H/6GKwxP8Gfo/yOvAf71T/xr8z6Wr4U/Xyvf/8AHhc/9cm/kaun8a9TKv8Aw5ejPnHw9Zrf63p9 pJ/q5p0RvoTz+lfb4mo6dKU10R+TYGiq2Jp03s5I2viTevdeK7qEnEFpiGJB0UADOB9a5cspqGHj Lq9WejxBXlUxkodI6JHLV6B4Z6Fq9pL4l8LeF7jrqMkxszIf4hzyfptz+deLRqRwuIqxXwpc39fe fW4qjLMMHhp/bcuW/wB/+X5lPVdR03w/eyabpWi2l59nOya5vIzI0jj72PQdq0pUauIiqtWo1fZI wxGJw+Cm6FCipcujcldt9StqumW2s6Va6potl9luJLgWtxaIflDn7rLnoDWlKtOhUdKrK6Sun5eZ jicJTxdGOIw8OWTlyuPS/Rr1NK1s7bTtQ/sfRtKtNW1SIf6Tc3hzGrd1UHgAdK5p1nOHta03CL2S 3O2jh6dCp9Ww1JVJpe85bX7IhmsLTXmvLE6bDpev2yGRFtz+6nA5Ix2PpirjWlQtUU+em3bXdEVc HTxTlRlS9nWirq20jlfD3/If0z/r6i/9CFeliP4U/wDC/wAj5/Af71T/AMa/M+lq+FP18r3/APx4 XP8A1yb+Rq6fxr1Mq/8ADl6M+aNOunsr62uo/vwSLIo9wc191VpqcJQfVH5BQrOjVjUXR3Oy8c6U 2qyL4j0VGubK7UGZYxuaFwMEMB9K8zAV/Zf7PV0cdvM+hznBvEv69h1zRktbbplXwRZWOrpcaPe6 fMZpjuivokJMJA6N6L/n3F46rOi1WhLRbruZ5Rh6WJjLDVabu9pJbevkdNqd1H4X1TwppUgYWdox kluGXCuzZBI+m4n2zXBSg8VCtVW7Wi9D18RUjl9bDYZ/DF3bto27/lcyvFniLxPous3ELXWLZnLW 8n2dCroTkYO3niujCYbB1qSlbXrq/wDM48yzDM8LXlFS92+jstunQsaXrOrf2d/bPiC5VYo226fH LGsYeZht3kADKqCTmoq4ejz+xoLX7XWy7fM0w2MxXsvrOLlon7iaSvJ6X22SMmSK98J3l2byA3Au BugvUyUcnPzZH1rzM5wlbM4UqmCqKMoaOL6rt6nTlNWGU4qSx0HOEnfmWvzHeA7e6s7u48R6qWS0 tUdxI4IErkEBVz1612qnKNBYZy5pyetuh14zMKeLxzzCFNwo04WV95M53QmL+ItOYgAtdxk4/wB8 V7mIVqMl/df5Hw2DlzYum+81+Z9KV8MfrpXv/wDjwuR/0yb+Rqqfxr1Ma/8ACl6M+YB0r79n431L mm6rqelSmTSr6a1c9QpyrfUHg1zYjDQrq01c7sHj62FlelKwuteJ/F2qQtBLrckULfeWBFiLfUqA a4FlVOLuj158R15x5ZP7tDPmuNXudFttLu9SlltLdi8SNyVJGOvXHXA7V0U8FGEnNbs4q2bTq01S lrFFvStf8VaTALey1pzbDhYp41lC/TcDisamWQnLmZ14fiCrRgorb7yrq9zq+tXAuNW1OW4mAwuQ Aqj0AHA/Cuijg40o8sNDhxWZzxM+apqSaNq/ifRF8rTNZlS3/wCeMiiRB9FYHH4VhVy6NR3e52Yb PatCPLHYm1HVNZ1eRX1jUpbnacqmAqL9FHFdGHwcKHwnFjs0q4v+I7os+Hv+Q9pn/X1F/wChCtsT /Cn6P8jnwH+9U/8AGvzPpavhT9eOU+Id9dQ6P9g0uGWa/vsxqsS5Kp/E3txxn3r0MupwdX2lR2jH X/I8bO69WND2NFNznpp26v8AQ43w/wDDC5m2y61cC3Tr5MJDP+J6D9a9TEZ1FaUlfzZ89guFakrS xMreS3+/b8zvLXwboFtAsS6XbyBf4pV3sfqTXjzzDEyldzZ9NTybAwjyqkn66k3/AAimg/8AQIsf +/Iqfr2I/nf3mn9k4L/n1H7g/wCEU0H/AKBFj/35FH17Efzv7w/snBf8+o/cH/CKaD/0CLH/AL8i j69iP5394f2Tgv8An1H7g/4RTQf+gRY/9+RR9exH87+8P7JwX/PqP3B/wimg/wDQIsf+/Io+vYj+ d/eH9k4L/n1H7g/4RTQf+gRY/wDfkUfXsR/O/vD+ycF/z6j9w+38NaLbzJNBpdmkqHcrrEAQfapl jK8lyubsVDLcJCSlGmk15I2K5zuCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgD/2Q== --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1028; creation-date="Tue, 10 Dec 2013 06:55:16 GMT"; modification-date="Tue, 10 Dec 2013 06:55:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECZQAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/AABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EAaIAAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQH BQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJico KSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/a AAwDAQACEQMRAD8Ax4/GE8sYkmt7CeVwGeSa0jkeQ9SWZgSSTySTXVfEy0j+HV/Hptvq2m3WqxoX uVttLW3azbarIVkA5J3ZBGCMc9a5DQ11fwZrVvqOmazBp2pWabMTLEHhfZsdSjt15Yciu2+PF/qf jHx3Pp39sQXNpaps060iWJ3DyQplRtO5izgdQfavqpxtUilbls2/l/w54sZ+5JvdNH1lRRRXyp7R /9k= --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1023; creation-date="Tue, 10 Dec 2013 06:55:16 GMT"; modification-date="Tue, 10 Dec 2013 06:55:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECIwAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/AABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EAaIAAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQH BQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJico KSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/a AAwDAQACEQMRAD8A971/x3aeEtE0q+uNPguIrqeKGeVgN0aspLSH5SWIwTjvV208X6N4h0O6v9Ka CWKIOokW3MbI4UHjIByMg5Fcdfyadq+h2un3mpRWVxbeWwLTKkkEqLjlWIOQcirR1r/iUz2kuuQa rdyoyRFPLV2LLhUCITnnv717DpUnT/vX/D+vM+WjiqqqWfw28t9b9U+vZ/I9qooorxz6k//Z --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1050; creation-date="Tue, 10 Dec 2013 06:55:16 GMT"; modification-date="Tue, 10 Dec 2013 06:55:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECIwAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/AABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EAaIAAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQH BQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJico KSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/a AAwDAQACEQMRAD8A9j8Sax4h0280660aGC4s2sRLcRtpwnzIHVCWKjeSwn8zAOT5HHBbNzwx4s1H XdMv21nw9BpcsFuHQi0aMhy0n3Sw5wFjOR3NeO+G7nwgtha6T4pmsbOS3eTzxKoimjYCEBXYDf18 8YJ69e1WvFv/AAr2/wBNuV8NyWlxrFxcsLeK1lckqyjYqR4xyxIwMY4xxXB/aDtdR+9/8A+unwnS hKMHWbut1C6W275l8+x9aUUUV3nyJ//Z --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image006.jpg" Content-Description: image006.jpg Content-Disposition: inline; filename="image006.jpg"; size=1025; creation-date="Tue, 10 Dec 2013 06:55:16 GMT"; modification-date="Tue, 10 Dec 2013 06:55:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECIwAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/CABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EABgAAAIDAAAAAAAAAAAAAAAAAAAB BAUH/8QAFAEBAAAAAAAAAAAAAAAAAAAABf/EABQCAQAAAAAAAAAAAAAAAAAAAAX/2gAMAwEAAhED IgAAAbxwGwHqwA7n/8QAGBABAQADAAAAAAAAAAAAAAAABQMABAb/2gAIAQEAAQUBPrTd0k4JERzn 3tcSSfRSWPz/xAAXEAADAQAAAAAAAAAAAAAAAAAREgAC/9oACAECAAEFAV0b/8QAFxAAAwEAAAAA AAAAAAAAAAAAERIAAv/aAAgBAwABBQE5W//aAAwDAQACEQMiAAAQW8//xAAkEAABAwMCBwEAAAAA AAAAAAACAQMEERIhMnEAEBMxQuEFIv/aAAgBAQAGPwF5wG3nXgVkRUbLamVv6rnK++Eclxij10FU VzuPKTHmtP8AUJ+OVBDT0zuVF4fhMhJN576RSGkIfBRog757cv/EABcQAAMBAAAAAAAAAAAAAAAA ACHxARD/2gAIAQIABj8BECz/xAAXEAADAQAAAAAAAAAAAAAAAAAh8QEQ/9oACAEDAAY/ATS8/8QA GxABAAICAwAAAAAAAAAAAAAAAREhMVEAEEH/2gAIAQEAAT8QdxOAp8mJwJ6zTg42ZgAkhWH0sakx 0RoDCxtREYoN5jkjkkJLBa2wEaev/8QAGhAAAQUBAAAAAAAAAAAAAAAAASGBkaEQUf/aAAgBAgAB PxAiQKriSWz/xAAbEAABBAMAAAAAAAAAAAAAAAABIYGREDFRYf/aAAgBAwABPxAEWIx3aAHr/9k= --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_ Content-Type: image/gif; name="image007.gif" Content-Description: image007.gif Content-Disposition: inline; filename="image007.gif"; size=493; creation-date="Tue, 10 Dec 2013 06:55:16 GMT"; modification-date="Tue, 10 Dec 2013 06:55:16 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_010_96747494E3D74D41B20907035DB1E48DCD72MOPESMBX03euthmulti_-- From swmike@swm.pp.se Mon Dec 9 23:10:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637371AE2CF; Mon, 9 Dec 2013 23:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-CmsT-ivLml; Mon, 9 Dec 2013 23:10:33 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id AE33B1AE2D1; Mon, 9 Dec 2013 23:10:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8D8969C; Tue, 10 Dec 2013 08:10:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 86C3F9A; Tue, 10 Dec 2013 08:10:27 +0100 (CET) Date: Tue, 10 Dec 2013 08:10:27 +0100 (CET) From: Mikael Abrahamsson To: Wuyts Carl In-Reply-To: <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> Message-ID: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org" , "" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 07:10:36 -0000 On Tue, 10 Dec 2013, Wuyts Carl wrote: > Again, you're binding WRONG the M to ia_na. this is really not good. > Let us implement standards based upon what they are designed for. The > M-flag was initially designed to flag the device to be Managed, not to >From RFC4861: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. I interpret this as M=1 means addresses are available via DHCPv6, that means IA_NA and/or IA_PD, one or both might be available. I don't really understand why you do not. What do you think the M flag means? Reading the above text seems to indicate that you think it has something to do with managing the CPE? > Just FYI. A lot of our customers don't even use ia_na. And yes, they > are using M=1, nearly all of them. That's fine. The CPE should however ask for both, if the network doesn't give ia_na to it, then that's fine. -- Mikael Abrahamsson email: swmike@swm.pp.se From leo.liubing@huawei.com Mon Dec 9 23:13:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556291AE1F5 for ; Mon, 9 Dec 2013 23:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHwPplkaaqko for ; Mon, 9 Dec 2013 23:13:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D9C1A1ADBCF for ; Mon, 9 Dec 2013 23:13:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYV16097; Tue, 10 Dec 2013 07:13:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 07:13:25 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 07:13:31 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 15:13:23 +0800 From: "Liubing (Leo)" To: "sarikaya@ieee.org" , Fred Baker Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO8PcjWuMJf8I9f0eBAQAUd5rlEZpLkRkAgAFqd6A= Date: Tue, 10 Dec 2013 07:13:23 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D823D27@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D823D27nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 07:13:51 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D823D27nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Behcet, Thanks for your comment. Please see replies inline. From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Tuesday, December 10, 2013 12:35 AM To: Fred Baker Cc: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org; v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Hi authors, I think this draft is requirements draft while draft-yourtchenko-ra-dhcpv6-= comparison-00.txt is problem statement draft for the same issue. [Bing] I think draft-yourtchenko-ra-dhcpv6-comparison is sort of guidance f= or the people who want to select between RA and DHCPv6 for designing mechan= isms, or operating the networks. Different scenarios might have different c= onsiderations as analyzed in the draft. But draft-ietf-v6ops-dhcpv6-slaac-problem reports currently existing issues= (mostly regarding with address configuration) that caused by either bad im= plementation or ambiguous standard definition. It should be a problem state= ment to warn people there might be issues if both SLAAC and DHCPv6 are avai= lable in one network, and also could be a trigger to revise current ambiguo= us definition in relevant standard (mostly regarding with RFC4861/RFC4862). My suggestion is requirements on delivering routes to the hosts also should= be added to this draft. [Bing] I'm not sure, because there hasn't been DHCP-based routes delivering= mechanism, so there hasn't been interaction problems so far. Maybe we coul= d consider this issue in the future. Best regards, Bing Regards, Behcet On Wed, Dec 4, 2013 at 7:45 AM, > wro= te: A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops= -dhcpv6-slaac-problem. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D823D27nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Behcet,=

 = ;

Thanks for= your comment. Please see replies inline.

 = ;

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Tuesday, December 10, 2013 12:35 AM
To: Fred Baker
Cc: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org; v6ops@ietf= .org
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-proble= m

 

= Hi authors,

= I think this draft is requirements draft while draft-yourtchenko-ra-dhcpv6-= comparison-00.txt is problem statement draft for the same issue.=

[Bing] I think draft-yourtchenko-ra-dhcpv6-comparison = is sort of guidance for the people who want to select between RA and DHCPv6 for designing mechanisms, or operating the networks. Differe= nt scenarios might have different considerations as analyzed in the draft.<= o:p>

But draft-ietf-v6ops-dhcpv6-slaac-problem reports curr= ently existing issues (mostly regarding with address configuration) that caused by either bad implementation or ambiguous standard definition.= It should be a problem statement to warn people there might be issues if b= oth SLAAC and DHCPv6 are available in one network, and also could be a trig= ger to revise current ambiguous definition in relevant standard (mostly regarding with RFC4861/RFC4862).

= My suggestion is requirements on delivering routes to the hosts also should= be added to this draft.

[Bing] I’m not sure, because there hasn’t = been DHCP-based routes delivering mechanism, so there hasn’t been int= eraction problems so far. Maybe we could consider this issue in the future.

Best regards,

Bing

= Regards,

Behcet

=  

On Wed, Dec 4, 2013 at 7:45 AM,= <fred@cisco.com= > wrote:


A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Pleas= e take a look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D823D27nkgeml506mbxchi_-- From Carl.Wuyts@technicolor.com Mon Dec 9 23:20:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FF91AE330; Mon, 9 Dec 2013 23:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P9tHVk92Y9Y; Mon, 9 Dec 2013 23:20:34 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id ABAEE1AE20B; Mon, 9 Dec 2013 23:20:30 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUqbAuboyTFGo7+L0ZPWlFq4Eg2dOWudk@postini.com; Mon, 09 Dec 2013 23:20:29 PST Received: from MOPESMAILHTC01.eu.thmulti.com (141.11.100.10) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 10 Dec 2013 08:13:13 +0100 Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.32]) by MOPESMAILHTC01.eu.thmulti.com ([141.11.100.10]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 08:13:15 +0100 From: Wuyts Carl To: Mikael Abrahamsson Thread-Topic: RFC7084 Thread-Index: Ac705Oox+bAOGgDPSBCf3B3p1FF6cAAA4TqgACKmQYD///b6gP//7wHQ Date: Tue, 10 Dec 2013 07:13:14 +0000 Message-ID: <96747494E3D74D41B20907035DB1E48DCE42@MOPESMBX03.eu.thmulti.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.11.249.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 07:20:39 -0000 -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: dinsdag 10 december 2013 8:10 To: Wuyts Carl Cc: STARK, BARBARA H; ; v6ops@ietf.org Subject: RE: RFC7084 On Tue, 10 Dec 2013, Wuyts Carl wrote: > Again, you're binding WRONG the M to ia_na. this is really not good.=20 > Let us implement standards based upon what they are designed for. The=20 > M-flag was initially designed to flag the device to be Managed, not to >From RFC4861: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. I interpret this as M=3D1 means addresses are available via DHCPv6, that me= ans IA_NA and/or IA_PD, one or both might be available. I don't really unde= rstand why you do not. What do you think the M flag means? Reading the abov= e text seems to indicate that you think it has something to do with managin= g the CPE? [Carl] Correct, as you state and/OR, not AND only. RFC7084 today says AND. > Just FYI. A lot of our customers don't even use ia_na. And yes, they=20 > are using M=3D1, nearly all of them. That's fine. The CPE should however ask for both, if the network doesn't gi= ve ia_na to it, then that's fine. [Carl] why ask for both ? Why making diff between the 2 if you always ask = for both ? Why not asking all options and just wait and see what you get b= ack ? --=20 Mikael Abrahamsson email: swmike@swm.pp.se From Carl.Wuyts@technicolor.com Tue Dec 10 00:55:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382A11ADF33 for ; Tue, 10 Dec 2013 00:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URH2wHkc5b8Y for ; Tue, 10 Dec 2013 00:55:34 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0651AE12E for ; Tue, 10 Dec 2013 00:55:30 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUqbW/RrwZuK6/g+m75BCffnlgCuVGh8j@postini.com; Tue, 10 Dec 2013 00:55:26 PST Received: from MOPESMAILHTC03.eu.thmulti.com (141.11.100.179) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 10 Dec 2013 09:49:46 +0100 Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.32]) by MOPESMAILHTC03.eu.thmulti.com ([141.11.100.179]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 09:49:48 +0100 From: Wuyts Carl To: "STARK, BARBARA H" Thread-Topic: RFC7084 Thread-Index: Ac705Oox+bAOGgDPSBCf3B3p1FF6cAAA4TqgACb6FAA= Date: Tue, 10 Dec 2013 08:49:47 +0000 Message-ID: <96747494E3D74D41B20907035DB1E48DCEE4@MOPESMBX03.eu.thmulti.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [141.11.249.10] Content-Type: multipart/related; boundary="_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 08:55:38 -0000 --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: multipart/alternative; boundary="_000_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_" --_000_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A final mail from me on this. First of all, someone pointed me to the fact that my mail was too rude and = too personal. The mail is NOT intended to be rude nor personal, so my apologies in case I= did insult anyone, this was really not the goal. So, again, this mail was just to flag RFC7084 inconsistency towards global = IPv6 standards (M-flag handling / dhcpv6 options) and nothing else. Regs Carl From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: maandag 9 december 2013 16:02 To: Wuyts Carl; Subject: RE: RFC7084 RFC7084-compliant CE routers are defined to work in an environment where th= e access network makes the rules. RFC7084-compliant CE routers, by definiti= on of the scope of that RFC, must be able to operate in the access networks= defined by CableLabs and BBF, at the very least. These CE routers don't ge= t to make the rules. The supported-for-interoperability access networks inc= lude ones that require IA_NA for proper operation. They also include ones t= hat do "unnumbered" model and use only IA_PD. They even include access netw= orks that support SLAAC + IA_PD (with no IA_NA). An RFC7084-compliant CE ro= uter will automatically work in all of these access networks, with no speci= al configuration. This was a core goal of the requirements in RFC7084. If an access network is designed to require CE routers to acquire IA_NA, th= en that CE router needs to acquire the IA_NA in order to function on that a= ccess network. This is not negotiable, and is not something the CE router c= an "choose" not to do because it doesn't feel like it. It was agreed that a= n access network that expects IA_NA to be requested will signal this by alw= ays setting M=3D1 in its RA messages. If the access network does not set M= =3D1, it cannot be sure the CE router will request IA_NA. If it does set M= =3D1, it *can* be sure the RFC7084-compliant CE router will request IA_NA. What was agreed, was that CE routers MUST request IA_NA if M=3D1 in the RA.= You are completely correct in your reading of the requirement. If the acce= ss network is designed so that IA_PD is enough, then it will not supply IA_= NA in response to the CE router's request. Such access networks have no dif= ficulty in not providing IA_NA. If the access network is designed to requi= re IA_NA, then it will supply the IA_NA in its response. Since nothing prev= ents the CE router from always requesting IA_NA, anyway, the access network= has to be resilient in the presence of such requests. The CE router is abl= e to work properly in both types of access networks. There is nothing in the description of the "M" bit in RFC 4861 that would f= orbid designing an IPv6 host to always request IA_NA whenever it sees M=3D1= . Therefore, this does not go against RFC 4861. Barbara From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Wuyts Carl Sent: Monday, December 09, 2013 9:02 AM To: > Subject: RFC7084 All, Not sure I should sent this one to DHCPv6 WG or the global IETF v6, so feel= free to forward it if needed. Last week, RFC7084 got posted. I did already post a message on a rather ba= dly phrased req (a SHOULD one regarding "long-enough", but bumped into the = next one today (this one being a lot worse!!). "" WAA-6: If the IPv6 CE router receives a Router Advertisement message (described in [RFC4861]) with the M flag set to 1, the IPv6 CE router MUST do DHCPv6 address assignment (request an IA_NA option). "" I'm not sure who came up with this one, but this is really a no-go. So, according to this req, the DHCPv6 client must request an ia_na option i= f an M=3D1 is being received on his link ??? I might have understood it al= l wrong, but as far as I know, M=3D1 is not linked directly to ia_na, ia_pd= is enough on its own, no ?? So, the CPE is expected to change its DHCPv6 = client configuration based upon receiving an RA with this M=3D1 content ? Extract from RFC4861: "" M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol "" I'm very curious on the replies now, but this seems really be going the wro= ng way. You can launch a CPE which either listen to RA or not, and bound a= ccordingly, however, listen + bind + force ia_na looks a bit too much to me= . regs Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [Visit technicolor.com] [Visit i-speak-qeo.com= ] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium www.technicolor.com - www.i-speak-qeo.com [Follow Technicolor on Facebook]Facebook [Follow Technicolor on Twitter]Twitter [Follow Technicolor on YouTube]YouTube [Follow Technicolor on LinkedIn]LinkedIn Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [Eco] Help preserve the color of our world - Think before you print. --_000_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A final= mail from me on this.

&n= bsp;

First o= f all, someone pointed me to the fact that my mail was too rude and too per= sonal.

The mai= l is NOT intended to be rude nor personal, so my apologies in case I did in= sult anyone, this was really not the goal.

&n= bsp;

So, aga= in, this mail was just to flag RFC7084 inconsistency towards global IPv6 st= andards (M-flag handling / dhcpv6 options) and nothing else.

&n= bsp;

Regs

Carl

&n= bsp;

&n= bsp;

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of STARK, BARBARA H
Sent: maandag 9 december 2013 16:02
To: Wuyts Carl; <ipv6@ietf.org>
Subject: RE: RFC7084

 

RFC7084-compliant CE routers ar= e defined to work in an environment where the access network makes the rule= s. RFC7084-compliant CE routers, by definition of the scope of that RFC, mu= st be able to operate in the access networks defined by CableLabs and BBF, at the very least. These CE routers= don’t get to make the rules. The supported-for-interoperability acce= ss networks include ones that require IA_NA for proper operation. They also= include ones that do “unnumbered” model and use only IA_PD. They even include access networks that support SLAAC &= #43; IA_PD (with no IA_NA). An RFC7084-compliant CE router will automatical= ly work in all of these access networks, with no special configuration. Thi= s was a core goal of the requirements in RFC7084.

 

If an access network is designe= d to require CE routers to acquire IA_NA, then that CE router needs to acqu= ire the IA_NA in order to function on that access network. This is not nego= tiable, and is not something the CE router can “choose” not to do because it doesn’t feel li= ke it. It was agreed that an access network that expects IA_NA to be reques= ted will signal this by always setting M=3D1 in its RA messages. If the acc= ess network does not set M=3D1, it cannot be sure the CE router will request IA_NA. If it does set M=3D1, it *can* be sur= e the RFC7084-compliant CE router will request IA_NA.

 

What was agreed, was that CE ro= uters MUST request IA_NA if M=3D1 in the RA. You are completely correct in = your reading of the requirement. If the access network is designed so that = IA_PD is enough, then it will not supply IA_NA in response to the CE router’s request. Such access networks h= ave no difficulty in not providing IA_NA.  If the access network is de= signed to require IA_NA, then it will supply the IA_NA in its response. Sin= ce nothing prevents the CE router from always requesting IA_NA, anyway, the access network has to be resilient in the pr= esence of such requests. The CE router is able to work properly in both typ= es of access networks.

 

There is nothing in the descrip= tion of the “M” bit in RFC 4861 that would forbid designing an = IPv6 host to always request IA_NA whenever it sees M=3D1. Therefore, this d= oes not go against RFC 4861.

Barbara

&n= bsp;

&n= bsp;

From: ipv6 [mailto= :ipv6-bounces@ietf.org] On Behalf Of Wuyts Carl
Sent: Monday, December 09, 2013 9:02 AM
To: <ipv6@ietf.org>
Subject: RFC7084

 

All,

 

Not sure I should sent this one= to DHCPv6 WG or the global IETF v6, so feel free to forward it if needed.<= o:p>

 

Last week, RFC7084 got posted.&= nbsp; I did already post a message on a rather badly phrased req (a SHOULD = one regarding “long-enough”, but bumped into the next one today= (this one being a lot worse!!).

 

“”

WA= A-6:   If the IPv6 CE router receives a Router Advertisement=

&n= bsp;           message (d= escribed in [RFC4861]) with the M flag set to 1,

&n= bsp;           the IPv6 C= E router MUST do DHCPv6 address assignment

&n= bsp;           (request a= n IA_NA option).

“”

I’m not sure who came up = with this one, but this is really a no-go.

So, according to this req, the = DHCPv6 client must request an ia_na option if an M=3D1 is being received on= his link ???  I might have understood it all wrong, but as far as I k= now, M=3D1 is not linked directly to ia_na, ia_pd is enough on its own, no ??  So, the CPE is expected to change its DH= CPv6 client configuration based upon receiving an RA with this M=3D1 conten= t ?

Extract from RFC4861:

“”

M           &nbs= p;  1-bit "Managed address configuration" flag.  When

            = ;         set, it indicates that ad= dresses are available via

            &nbs= p;        Dynamic Host= Configuration Protocol

 

“”

 

 

I’m very curious on the r= eplies now, but this seems really be going the wrong way.  You can lau= nch a CPE which either listen to RA or not, and bound accordingly, however,= listen + bind + force ia_na looks a bit too much to me.

 

regs 

Carl Wuyts

GCD System Architect Ne= tworking

c= arl.wuyts@technicolor.com

tel.: +32 3 443 65 = 90

3D"Visit 3D"Visit

Prins Boudewijnlaan 47&= nbsp; -  2650 Edegem  -  Belgium

www.technicolor.com - www.i-speak-qeo.com

3D"FollowFacebook<= /span>

3D"FollowTwitter<= /a>

3D"FollowYouTube

Lin= kedIn

Technicolor Delivery Tech= nologies Belgium NV

Registered office (maatsc= happelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium<= /span>

Company registration numb= er (ondernemingsnummer): 0428837295 - RPR Antwerpen

3D"Eco"

Help preserve the = color of our world - Think before you print.

 

 

--_000_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_-- --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1834; creation-date="Tue, 10 Dec 2013 08:49:46 GMT"; modification-date="Tue, 10 Dec 2013 08:49:46 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2740; creation-date="Tue, 10 Dec 2013 08:49:46 GMT"; modification-date="Tue, 10 Dec 2013 08:49:46 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEAYABgAAD/wAARCABFAFYDAREAAhEBAxEB/9sAhAAGBAUGBQQGBgUGBwcG CAoRCwoJCQoVDxAMERkWGhoYFhgXGx8oIRsdJR4XGCIvIyUpKiwtLBshMTQwKzQoKywrAQcHBwoJ ChQLCxQrHBgcHCsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr Kyv/xAGiAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgsQAAIBAwMCBAMFBQQEAAABfQECAwAE EQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZH SElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1 tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+gEAAwEBAQEBAQEBAQAA AAAAAAECAwQFBgcICQoLEQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGh scEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlq c3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APqmgAoAKACgAoAKACgAoAKACgAo ASR1jRnc4VRkn0FNK7shSkoq7OOPxJ8OZ/4+Jz/2xavT/sjE9l954P8ArNgP5n9wf8LJ8O/897j/ AL8NS/sjE9l94f6zYD+Z/cH/AAsjw7/z3uP+/DUf2Riey+8P9ZcB3f3B/wALJ8O/895/+/LUf2Ri ey+8P9ZsB/M/uD/hZPh3/nvP/wB+Gp/2Riey+8X+s2A/mf3B/wALJ8O/895/+/DUf2Riey+8P9Zs B/M/uD/hZPh3/nvP/wB+Go/sjE9l94f6zYD+Z/cH/CyfDv8Az3n/AO/DUf2Riey+8P8AWbAfzP7i az+IOgXd3DbRTzeZK4Rd0LAZJwKieVYmEXJrReZrS4hwVWahGTu3bY6yvOPbK9//AMeFz/1zb+VX T+NeplX/AIcvRnzCOlffH42dPpPhdG01NT12+TTbCT/Vbl3SS/7q+ledWxrU/ZUY80lv2R7eFymL pKvip8kHt3foi3BoXhnU3FvpWuTRXbcIt5FtWQ+mRjFZyxWLpLmqU9PJm8Mvy7EPkoVmpf3lozmd W0660m/ls76IxzIeR2I7EHuK76NaFWCnDY8XFYWrhqrpVFZop1sc1gouFgouFgoCxoeHv+Q/pn/X 1H/6GKwxP8Gfo/yOvAf71T/xr8z6Wr4U/Xyvf/8AHhc/9cm/kaun8a9TKv8Aw5ejPnHw9Zrf63p9 pJ/q5p0RvoTz+lfb4mo6dKU10R+TYGiq2Jp03s5I2viTevdeK7qEnEFpiGJB0UADOB9a5cspqGHj Lq9WejxBXlUxkodI6JHLV6B4Z6Fq9pL4l8LeF7jrqMkxszIf4hzyfptz+deLRqRwuIqxXwpc39fe fW4qjLMMHhp/bcuW/wB/+X5lPVdR03w/eyabpWi2l59nOya5vIzI0jj72PQdq0pUauIiqtWo1fZI wxGJw+Cm6FCipcujcldt9StqumW2s6Va6potl9luJLgWtxaIflDn7rLnoDWlKtOhUdKrK6Sun5eZ jicJTxdGOIw8OWTlyuPS/Rr1NK1s7bTtQ/sfRtKtNW1SIf6Tc3hzGrd1UHgAdK5p1nOHta03CL2S 3O2jh6dCp9Ww1JVJpe85bX7IhmsLTXmvLE6bDpev2yGRFtz+6nA5Ix2PpirjWlQtUU+em3bXdEVc HTxTlRlS9nWirq20jlfD3/If0z/r6i/9CFeliP4U/wDC/wAj5/Af71T/AMa/M+lq+FP18r3/APx4 XP8A1yb+Rq6fxr1Mq/8ADl6M+aNOunsr62uo/vwSLIo9wc191VpqcJQfVH5BQrOjVjUXR3Oy8c6U 2qyL4j0VGubK7UGZYxuaFwMEMB9K8zAV/Zf7PV0cdvM+hznBvEv69h1zRktbbplXwRZWOrpcaPe6 fMZpjuivokJMJA6N6L/n3F46rOi1WhLRbruZ5Rh6WJjLDVabu9pJbevkdNqd1H4X1TwppUgYWdox kluGXCuzZBI+m4n2zXBSg8VCtVW7Wi9D18RUjl9bDYZ/DF3bto27/lcyvFniLxPous3ELXWLZnLW 8n2dCroTkYO3niujCYbB1qSlbXrq/wDM48yzDM8LXlFS92+jstunQsaXrOrf2d/bPiC5VYo226fH LGsYeZht3kADKqCTmoq4ejz+xoLX7XWy7fM0w2MxXsvrOLlon7iaSvJ6X22SMmSK98J3l2byA3Au BugvUyUcnPzZH1rzM5wlbM4UqmCqKMoaOL6rt6nTlNWGU4qSx0HOEnfmWvzHeA7e6s7u48R6qWS0 tUdxI4IErkEBVz1612qnKNBYZy5pyetuh14zMKeLxzzCFNwo04WV95M53QmL+ItOYgAtdxk4/wB8 V7mIVqMl/df5Hw2DlzYum+81+Z9KV8MfrpXv/wDjwuR/0yb+Rqqfxr1Ma/8ACl6M+YB0r79n431L mm6rqelSmTSr6a1c9QpyrfUHg1zYjDQrq01c7sHj62FlelKwuteJ/F2qQtBLrckULfeWBFiLfUqA a4FlVOLuj158R15x5ZP7tDPmuNXudFttLu9SlltLdi8SNyVJGOvXHXA7V0U8FGEnNbs4q2bTq01S lrFFvStf8VaTALey1pzbDhYp41lC/TcDisamWQnLmZ14fiCrRgorb7yrq9zq+tXAuNW1OW4mAwuQ Aqj0AHA/Cuijg40o8sNDhxWZzxM+apqSaNq/ifRF8rTNZlS3/wCeMiiRB9FYHH4VhVy6NR3e52Yb PatCPLHYm1HVNZ1eRX1jUpbnacqmAqL9FHFdGHwcKHwnFjs0q4v+I7os+Hv+Q9pn/X1F/wChCtsT /Cn6P8jnwH+9U/8AGvzPpavhT9eOU+Id9dQ6P9g0uGWa/vsxqsS5Kp/E3txxn3r0MupwdX2lR2jH X/I8bO69WND2NFNznpp26v8AQ43w/wDDC5m2y61cC3Tr5MJDP+J6D9a9TEZ1FaUlfzZ89guFakrS xMreS3+/b8zvLXwboFtAsS6XbyBf4pV3sfqTXjzzDEyldzZ9NTybAwjyqkn66k3/AAimg/8AQIsf +/Iqfr2I/nf3mn9k4L/n1H7g/wCEU0H/AKBFj/35FH17Efzv7w/snBf8+o/cH/CKaD/0CLH/AL8i j69iP5394f2Tgv8An1H7g/4RTQf+gRY/9+RR9exH87+8P7JwX/PqP3B/wimg/wDQIsf+/Io+vYj+ d/eH9k4L/n1H7g/4RTQf+gRY/wDfkUfXsR/O/vD+ycF/z6j9w+38NaLbzJNBpdmkqHcrrEAQfapl jK8lyubsVDLcJCSlGmk15I2K5zuCgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgD/2Q== --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1028; creation-date="Tue, 10 Dec 2013 08:49:46 GMT"; modification-date="Tue, 10 Dec 2013 08:49:46 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECZQAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/AABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EAaIAAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQH BQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJico KSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/a AAwDAQACEQMRAD8Ax4/GE8sYkmt7CeVwGeSa0jkeQ9SWZgSSTySTXVfEy0j+HV/Hptvq2m3WqxoX uVttLW3azbarIVkA5J3ZBGCMc9a5DQ11fwZrVvqOmazBp2pWabMTLEHhfZsdSjt15Yciu2+PF/qf jHx3Pp39sQXNpaps060iWJ3DyQplRtO5izgdQfavqpxtUilbls2/l/w54sZ+5JvdNH1lRRRXyp7R /9k= --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1023; creation-date="Tue, 10 Dec 2013 08:49:47 GMT"; modification-date="Tue, 10 Dec 2013 08:49:47 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECIwAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/AABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EAaIAAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQH BQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJico KSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/a AAwDAQACEQMRAD8A971/x3aeEtE0q+uNPguIrqeKGeVgN0aspLSH5SWIwTjvV208X6N4h0O6v9Ka CWKIOokW3MbI4UHjIByMg5Fcdfyadq+h2un3mpRWVxbeWwLTKkkEqLjlWIOQcirR1r/iUz2kuuQa rdyoyRFPLV2LLhUCITnnv717DpUnT/vX/D+vM+WjiqqqWfw28t9b9U+vZ/I9qooorxz6k//Z --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1050; creation-date="Tue, 10 Dec 2013 08:49:47 GMT"; modification-date="Tue, 10 Dec 2013 08:49:47 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECIwAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/AABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EAaIAAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi 4+Tl5ufo6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQH BQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJico KSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/a AAwDAQACEQMRAD8A9j8Sax4h0280660aGC4s2sRLcRtpwnzIHVCWKjeSwn8zAOT5HHBbNzwx4s1H XdMv21nw9BpcsFuHQi0aMhy0n3Sw5wFjOR3NeO+G7nwgtha6T4pmsbOS3eTzxKoimjYCEBXYDf18 8YJ69e1WvFv/AAr2/wBNuV8NyWlxrFxcsLeK1lckqyjYqR4xyxIwMY4xxXB/aDtdR+9/8A+unwnS hKMHWbut1C6W275l8+x9aUUUV3nyJ//Z --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: image/jpeg; name="image006.jpg" Content-Description: image006.jpg Content-Disposition: inline; filename="image006.jpg"; size=1025; creation-date="Tue, 10 Dec 2013 08:49:47 GMT"; modification-date="Tue, 10 Dec 2013 08:49:47 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgIAyADIAAD//gECIwAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAA AAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQ AAAAAAAAAAAAAAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAA AAEAAAAAEAAAAAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAA AAAAAAAAAAABAAAAABAAAAAAAAAAAAAAAQAAAAAQAAAAAAAAAAAAAAEAAAAAEAAAAAAAAP/CABEI ABAAFAMBIgACEQEDEQH/2wCEAAUDAwQDAwUEBAQFBQUGBw0IBwcHBxALDAkNExAUExIQEhIVFx4Z FRYcFhISGiMaHB8gISIhFBklJyQgJx4hISABBQUFBwYHDwgIDyAVEhUVICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIP/EABgAAAIDAAAAAAAAAAAAAAAAAAAB BAUH/8QAFAEBAAAAAAAAAAAAAAAAAAAABf/EABQCAQAAAAAAAAAAAAAAAAAAAAX/2gAMAwEAAhED IgAAAbxwGwHqwA7n/8QAGBABAQADAAAAAAAAAAAAAAAABQMABAb/2gAIAQEAAQUBPrTd0k4JERzn 3tcSSfRSWPz/xAAXEAADAQAAAAAAAAAAAAAAAAAREgAC/9oACAECAAEFAV0b/8QAFxAAAwEAAAAA AAAAAAAAAAAAERIAAv/aAAgBAwABBQE5W//aAAwDAQACEQMiAAAQW8//xAAkEAABAwMCBwEAAAAA AAAAAAACAQMEERIhMnEAEBMxQuEFIv/aAAgBAQAGPwF5wG3nXgVkRUbLamVv6rnK++Eclxij10FU VzuPKTHmtP8AUJ+OVBDT0zuVF4fhMhJN576RSGkIfBRog757cv/EABcQAAMBAAAAAAAAAAAAAAAA ACHxARD/2gAIAQIABj8BECz/xAAXEAADAQAAAAAAAAAAAAAAAAAh8QEQ/9oACAEDAAY/ATS8/8QA GxABAAICAwAAAAAAAAAAAAAAAREhMVEAEEH/2gAIAQEAAT8QdxOAp8mJwJ6zTg42ZgAkhWH0sakx 0RoDCxtREYoN5jkjkkJLBa2wEaev/8QAGhAAAQUBAAAAAAAAAAAAAAAAASGBkaEQUf/aAAgBAgAB PxAiQKriSWz/xAAbEAABBAMAAAAAAAAAAAAAAAABIYGREDFRYf/aAAgBAwABPxAEWIx3aAHr/9k= --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_ Content-Type: image/gif; name="image007.gif" Content-Description: image007.gif Content-Disposition: inline; filename="image007.gif"; size=493; creation-date="Tue, 10 Dec 2013 08:49:47 GMT"; modification-date="Tue, 10 Dec 2013 08:49:47 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_010_96747494E3D74D41B20907035DB1E48DCEE4MOPESMBX03euthmulti_-- From Carl.Wuyts@technicolor.com Tue Dec 10 03:03:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C3C1ADDD3 for ; Tue, 10 Dec 2013 03:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPOfKFELs0Ot for ; Tue, 10 Dec 2013 03:03:30 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id AE17A1ADDD2 for ; Tue, 10 Dec 2013 03:03:29 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUqb0/Bq+dXqq1I2cllqZdAHoEZlbKF2g@postini.com; Tue, 10 Dec 2013 03:03:25 PST Received: from MOPESMAILHTC01.eu.thmulti.com (141.11.100.10) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 10 Dec 2013 11:59:46 +0100 Received: from MOPESMBX03.eu.thmulti.com ([169.254.2.32]) by MOPESMAILHTC01.eu.thmulti.com ([141.11.100.10]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 11:59:48 +0100 From: Wuyts Carl To: "v6ops@ietf.org" Thread-Topic: RFC7084 - WPD-4 Thread-Index: Ac71k1LDzus6j594S264JoxlSCPyrQ== Date: Tue, 10 Dec 2013 10:59:47 +0000 Message-ID: <96747494E3D74D41B20907035DB1E48DCFAB@MOPESMBX03.eu.thmulti.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.11.249.10] Content-Type: multipart/alternative; boundary="_000_96747494E3D74D41B20907035DB1E48DCFABMOPESMBX03euthmulti_" MIME-Version: 1.0 Subject: [v6ops] RFC7084 - WPD-4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 11:03:33 -0000 --_000_96747494E3D74D41B20907035DB1E48DCFABMOPESMBX03euthmulti_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, Although I did not plan to send another mail on these reqs, I've got a ques= tion on the below, as I'm fully lost now I'm afraid. WPD-4 By default, the IPv6 CE router MUST initiate DHCPv6 prefix delegation= when either the M or O flags are set to 1 in a received Router Advertiseme= nt (RA) message. Behavior of the CE router to use DHCPv6 prefix delegation when the CE router has= not received any RA or received an RA with the M and the O bits set to zer= o is out of scope for this document. If I read this, this req says: "do stateful dhcpv6 (ia_pd) in case of M-fla= g=3D1 OR O-flag=3D1 in the received RA". Right or not ??? If this statement is correct, I'm totally lost. According to what I read i= n RFC4861 and 3315. O=3D1 means "other configuration" means "information-r= equest" DHCPv6 messages i.s.o. solicit, meaning not (allowed) to add statef= ul options (IA_INA/IA_PD options) ??? Moreover, extract from RFC3633: "" A requesting router first creates an IA_PD and assigns it an IAID. The requesting router then transmits a Solicit message containing an IA_PD option describing the IA_PD. Delegating routers that can delegate prefixes to the IA_PD respond to the requesting router with an Advertise message. "" summary: Other Stateful Configuration Flag , which is also known as the O flag. When set to 1, this flag instructs the host to use a configuration protocol= to obtain other configuration settings. Combining the values of the M and O flags can yield the following: Both M and O Flags are Set to 0. This combination corresponds to a network = without a DHCPv6 infrastructure. Hosts use router advertisements for non-link-local addresses and other meth= ods (such as manual configuration) to configure other settings. Both M and O Flags are Set to 1. DHCPv6 is used for both addresses and othe= r configuration settings. This combination is known as DHCPv6 stateful, in which DHCPv6 is assigning = stateful addresses to IPv6 hosts. The M Flag is Set to 0 and the O Flag is Set to 1. DHCPv6 is not used to as= sign addresses, only to assign other configuration settings. Neighboring routers are configured to advertise non-link-local address pref= ixes from which IPv6 hosts derive stateless addresses. This combination is = known as DHCPv6 stateless: DHCPv6 is not assigning stateful addresses to IPv6 hosts,= but stateless configuration settings. The M Flag is Set to 1 and the O Flag is Set to 0. In this combination, DHC= Pv6 is used for address configuration but not for other settings. Because I= Pv6 hosts typically need to be configured with other settings, such as the = IPv6 addresses of Domain Name System (DNS) servers, this is an unlikely com= bination. Regs Carl --_000_96747494E3D74D41B20907035DB1E48DCFABMOPESMBX03euthmulti_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So= ,

 

Al= though I did not plan to send another mail on these reqs, I’ve got a = question on the below, as I’m fully lost now I’m afraid.

 

WP= D-4 By default, the IPv6 CE router MUST initiate DHCPv6 prefix delegation w= hen either the M or O flags are set to 1 in a received Router Advertisement (RA) message.  Behavior of the=

&n= bsp;          CE router to use= DHCPv6 prefix delegation when the CE router has not received any RA or rec= eived an RA with the M and the O bits set to zero is out of scope for this document.

 

 

If I read this, this req says: = “do stateful dhcpv6 (ia_pd) in case of M-flag=3D1 OR O-flag=3D1 in th= e received RA”.

Right or not ???

 

If this statement is correct, I= ’m totally lost.  According to what I read in RFC4861 and 3315.&= nbsp; O=3D1 means “other configuration” means “informatio= n-request” DHCPv6 messages i.s.o. solicit, meaning not (allowed) to add statef= ul options (IA_INA/IA_PD options) ???=

Moreover, extract from RFC3633:=

“”

A requesting router first creat= es an IA_PD and assigns it an IAID.

   The requesting rou= ter then transmits a Solicit message containing an

   IA_PD option descr= ibing the IA_PD.  Delegating routers that can

   delegate prefixes = to the IA_PD respond to the requesting router with

   an Advertise message.

 

“”

 

summary:

 

Other Stateful Configuration Flag&n= bsp;, which is also known as the O flag.

When set to 1, this flag instructs the= host to use a configuration protocol to obtain other configuration setting= s.

Combining the values of the M and O fl= ags can yield the following: 

Both M and O Flags are Set to 0.&nb= sp;This combination corresponds to a network without a DHCPv6 infrastructure.

Hosts use router advertisements for no= n-link-local addresses and other methods (such as manual configuration) to = configure other settings.<= o:p>

 

Both M and O Flags are Set to 1.&nb= sp;DHCPv6 is used for both addresses and other configuration settings.

This combination is known as DHCPv6 st= ateful, in which DHCPv6 is assigning stateful addresses to IPv6 hosts.

 

The M Flag is Set to 0 and the O Fl= ag is Set to 1. DHCPv6 is not used to assign addresses, only to assign other configuration settings.

Neighboring routers are configured to = advertise non-link-local address prefixes from which IPv6 hosts derive stat= eless addresses. This combination is known as

DHCPv6 stateless: DHCPv6 is not assign= ing stateful addresses to IPv6 hosts, but stateless configuration settings.=

 

The M Flag is Set to 1 and the O Fl= ag is Set to 0. In this combination, DHCPv6 is used for address configuration but not for other settings. Because IPv6 ho= sts typically need to be configured with other settings, such as the IPv6 a= ddresses of Domain Name System (DNS) servers, this is an unlikely combinati= on.

 

 

Regs

Carl

--_000_96747494E3D74D41B20907035DB1E48DCFABMOPESMBX03euthmulti_-- From sander@steffann.nl Tue Dec 10 03:08:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4271ACAD7; Tue, 10 Dec 2013 03:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEKu4ZB1xKDq; Tue, 10 Dec 2013 03:08:58 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1101A1F54; Tue, 10 Dec 2013 03:08:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7EDA653; Tue, 10 Dec 2013 12:08:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wL1ciNd5Xvs; Tue, 10 Dec 2013 12:08:50 +0100 (CET) Received: from [IPv6:2001:9e0:4:12:d428:4cf7:52f4:c052] (unknown [IPv6:2001:9e0:4:12:d428:4cf7:52f4:c052]) by mail.sintact.nl (Postfix) with ESMTPSA id 532BC34; Tue, 10 Dec 2013 12:08:50 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Sander Steffann In-Reply-To: Date: Tue, 10 Dec 2013 12:08:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org" , "" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 11:09:00 -0000 Hi Mikael, Op 10 dec. 2013, om 08:10 heeft Mikael Abrahamsson = het volgende geschreven: > =46rom RFC4861: >=20 > M 1-bit "Managed address configuration" flag. When > set, it indicates that addresses are available via > Dynamic Host Configuration Protocol [DHCPv6]. >=20 > I interpret this as M=3D1 means addresses are available via DHCPv6, = that means IA_NA and/or IA_PD, one or both might be available. I don't = really understand why you do not. What do you think the M flag means? = Reading the above text seems to indicate that you think it has something = to do with managing the CPE? As far as I know the M flag is linked only to IA_NA. As far as I can see = IA_PD is not linked to the M flag at all. Cheers, Sander From sander@steffann.nl Tue Dec 10 03:22:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106CC1ADF89 for ; Tue, 10 Dec 2013 03:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W899glhMgmSq for ; Tue, 10 Dec 2013 03:22:50 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 734471AD7C0 for ; Tue, 10 Dec 2013 03:22:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 1B25D53; Tue, 10 Dec 2013 12:22:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rkFDPZuPxcW; Tue, 10 Dec 2013 12:22:42 +0100 (CET) Received: from [IPv6:2001:9e0:4:12:d428:4cf7:52f4:c052] (unknown [IPv6:2001:9e0:4:12:d428:4cf7:52f4:c052]) by mail.sintact.nl (Postfix) with ESMTPSA id 8708D34; Tue, 10 Dec 2013 12:22:42 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Sander Steffann In-Reply-To: <96747494E3D74D41B20907035DB1E48DCFAB@MOPESMBX03.eu.thmulti.com> Date: Tue, 10 Dec 2013 12:22:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96747494E3D74D41B20907035DB1E48DCFAB@MOPESMBX03.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 - WPD-4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 11:22:52 -0000 Hi, Op 10 dec. 2013, om 11:59 heeft Wuyts Carl = het volgende geschreven: > WPD-4 By default, the IPv6 CE router MUST initiate DHCPv6 prefix = delegation when either the M or O flags are set to 1 in a received = Router Advertisement (RA) message. Behavior of the > CE router to use DHCPv6 prefix delegation when the CE = router has not received any RA or received an RA with the M and the O = bits set to zero is out of scope for this document. > =20 > If I read this, this req says: =93do stateful dhcpv6 (ia_pd) in case = of M-flag=3D1 OR O-flag=3D1 in the received RA=94. > Right or not ??? Right, although 'out-of-scope' doesn't mean 'don't try IA_PD'. I = personally wouldn't have tied IA_PD to the M or O flag at all: a CPE = cannot properly work without IA_PD so I see no reason to not use it = always. WPD-4 seems overly restrictive to me (wish I spotted that = before, bit late now). I would have preferred it to just read: "the IPv6 = CE router MUST always initiate DHCPv6 prefix delegation", although this = is still possible even with the current wording. > If this statement is correct, I=92m totally lost. According to what I = read in RFC4861 and 3315. O=3D1 means =93other configuration=94 means = =93information-request=94 DHCPv6 messages i.s.o. solicit, meaning not = (allowed) to add stateful options (IA_INA/IA_PD options) ??? The M and O flag are indications. It is not forbidden to have a stateful = DHCPv6 server on the LAN even if you don't advertise it with the M flag. > Moreover, extract from RFC3633: > =93=94 > A requesting router first creates an IA_PD and assigns it an IAID. > The requesting router then transmits a Solicit message containing = an > IA_PD option describing the IA_PD. Delegating routers that can > delegate prefixes to the IA_PD respond to the requesting router = with > an Advertise message. > =20 > =93=94 > =20 > summary: > =20 > Other Stateful Configuration Flag , which is also known as the O flag. > When set to 1, this flag instructs the host to use a configuration = protocol to obtain other configuration settings. > Combining the values of the M and O flags can yield the following: > =20 > Both M and O Flags are Set to 0. This combination corresponds to a = network without a DHCPv6 infrastructure. Not necessarily. I have seen lots of networks that offer IA_PD on such a = network. > Hosts use router advertisements for non-link-local addresses and other = methods (such as manual configuration) to configure other settings. That is more dependent on the A(utoconf) flag in the prefix options. It = is possible to configure a network to use both DHCPv6 IA_NA and Autoconf = at the same time. Manual configuration is always possible of course. > Both M and O Flags are Set to 1. DHCPv6 is used for both addresses and = other configuration settings. > This combination is known as DHCPv6 stateful, in which DHCPv6 is = assigning stateful addresses to IPv6 hosts. The way you write it sounds too strict to me. M=3D1 means that IA_NA = addresses could be obtained from a stateful DHCPv6 server. It doesn't = exclude other ways of configuration (autoconf, manual). > The M Flag is Set to 0 and the O Flag is Set to 1. DHCPv6 is not used = to assign addresses, only to assign other configuration settings. Ack > Neighboring routers are configured to advertise non-link-local address = prefixes from which IPv6 hosts derive stateless addresses. That is the A flag in the prefix option again. It doesn't have to be = set, but if it isn't set in any of the prefixes then manual = configuration is required. > This combination is known as > DHCPv6 stateless: DHCPv6 is not assigning stateful addresses to IPv6 = hosts, but stateless configuration settings. That is the most common way to do it yes. > The M Flag is Set to 1 and the O Flag is Set to 0. In this = combination, DHCPv6 is used for address configuration but not for other = settings. Because IPv6 hosts typically need to be configured with other = settings, such as the IPv6 addresses of Domain Name System (DNS) = servers, this is an unlikely combination. If the M flag is set the O flag doesn't really have a meaning anymore as = far as I know. Cheers, Sander From otroan@employees.org Tue Dec 10 06:54:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6721ADF8D for ; Tue, 10 Dec 2013 06:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuLPMTpgcxNm for ; Tue, 10 Dec 2013 06:54:44 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0F62F1ADC03 for ; Tue, 10 Dec 2013 06:54:43 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAEYqp1KQ/khL/2dsb2JhbABZgwc4uXCBHRZ0giUBAQEDAQEBAWsLBQsLRicwBhOHfAYNwQgTBI40AQFPB4MhgRMEkDGZdoMqO4EsBwIX X-IronPort-AV: E=Sophos;i="4.93,865,1378857600"; d="asc'?scan'208";a="1354977" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 10 Dec 2013 14:54:37 +0000 Received: from dhcp-10-61-107-220.cisco.com (dhcp-10-61-107-220.cisco.com [10.61.107.220]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBAEsW2O030099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 14:54:34 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_728603B2-2961-4270-8EDE-A09F9333DA6C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <96747494E3D74D41B20907035DB1E48DCFAB@MOPESMBX03.eu.thmulti.com> Date: Tue, 10 Dec 2013 15:54:31 +0100 Message-Id: <26A64B52-B33A-49C2-B82B-F910913CE3C5@employees.org> References: <96747494E3D74D41B20907035DB1E48DCFAB@MOPESMBX03.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 - WPD-4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 14:54:45 -0000 --Apple-Mail=_728603B2-2961-4270-8EDE-A09F9333DA6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Carl, I agree with you. I believe the WPD-4 in RFC6204 is correct and not the = one in RFC7084. cheers, Ole > Although I did not plan to send another mail on these reqs, I=92ve got = a question on the below, as I=92m fully lost now I=92m afraid. > =20 > WPD-4 By default, the IPv6 CE router MUST initiate DHCPv6 prefix = delegation when either the M or O flags are set to 1 in a received = Router Advertisement (RA) message. Behavior of the > CE router to use DHCPv6 prefix delegation when the CE = router has not received any RA or received an RA with the M and the O = bits set to zero is out of scope for this document. > =20 > =20 > If I read this, this req says: =93do stateful dhcpv6 (ia_pd) in case = of M-flag=3D1 OR O-flag=3D1 in the received RA=94. > Right or not ??? > =20 > If this statement is correct, I=92m totally lost. According to what I = read in RFC4861 and 3315. O=3D1 means =93other configuration=94 means = =93information-request=94 DHCPv6 messages i.s.o. solicit, meaning not = (allowed) to add stateful options (IA_INA/IA_PD options) ??? > Moreover, extract from RFC3633: > =93=94 > A requesting router first creates an IA_PD and assigns it an IAID. > The requesting router then transmits a Solicit message containing = an > IA_PD option describing the IA_PD. Delegating routers that can > delegate prefixes to the IA_PD respond to the requesting router = with > an Advertise message. > =20 > =93=94 > =20 > summary: > =20 > Other Stateful Configuration Flag , which is also known as the O flag. > When set to 1, this flag instructs the host to use a configuration = protocol to obtain other configuration settings. > Combining the values of the M and O flags can yield the following: > =20 > Both M and O Flags are Set to 0. This combination corresponds to a = network without a DHCPv6 infrastructure. > Hosts use router advertisements for non-link-local addresses and other = methods (such as manual configuration) to configure other settings. > =20 > Both M and O Flags are Set to 1. DHCPv6 is used for both addresses and = other configuration settings. > This combination is known as DHCPv6 stateful, in which DHCPv6 is = assigning stateful addresses to IPv6 hosts. > =20 > The M Flag is Set to 0 and the O Flag is Set to 1. DHCPv6 is not used = to assign addresses, only to assign other configuration settings. > Neighboring routers are configured to advertise non-link-local address = prefixes from which IPv6 hosts derive stateless addresses. This = combination is known as > DHCPv6 stateless: DHCPv6 is not assigning stateful addresses to IPv6 = hosts, but stateless configuration settings. > =20 > The M Flag is Set to 1 and the O Flag is Set to 0. In this = combination, DHCPv6 is used for address configuration but not for other = settings. Because IPv6 hosts typically need to be configured with other = settings, such as the IPv6 addresses of Domain Name System (DNS) = servers, this is an unlikely combination. > =20 > =20 > Regs > Carl > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_728603B2-2961-4270-8EDE-A09F9333DA6C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSpysnAAoJEFuJXizso86gUuwIAJ0rz2O4UsFElb4mH1FoOWSI WvpOyGl/FYGEHYO+UGIepm4eZRlzHOr20LlZ/n2NRGdfJIGPN7jBkyCFHawfH8Ag Eg/a1BWb4nbjJgtU5VVan+7KEPbQfUarD5Kaos4QLfnVkvCkoBO/4FofNjxGUkuM kXvhjuKjL5E/N6TdnT/vMkAKIhE07s2YuN+Oxfin/eIZL0CqJKknkWjAFnJ1vaDl NnLAO6FsBf7GYDy/SiIoj8VZQsJElD00XbjU/5u8Xb2TFEygQDocgY77jSqdEEBL f4H3d6tO57P2hEdxAKQxxaDjcTrE004K7avhtNk2+vMmZgjRkL0EZSYr3Og1rLQ= =Sqiq -----END PGP SIGNATURE----- --Apple-Mail=_728603B2-2961-4270-8EDE-A09F9333DA6C-- From Ted.Lemon@nominum.com Tue Dec 10 08:51:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED751AE18D; Tue, 10 Dec 2013 08:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0H96_t4DdYq; Tue, 10 Dec 2013 08:51:52 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id B73A81AE190; Tue, 10 Dec 2013 08:51:52 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUqdGo/CDhGgEPYE/lwfO4A8nI3am72jk@postini.com; Tue, 10 Dec 2013 08:51:47 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 49ED01B8307; Tue, 10 Dec 2013 08:51:47 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2974D190052; Tue, 10 Dec 2013 08:51:47 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 08:51:46 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Tue, 10 Dec 2013 11:51:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> To: Sander Steffann X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" , "" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:51:54 -0000 On Dec 10, 2013, at 6:08 AM, Sander Steffann wrote: > As far as I know the M flag is linked only to IA_NA. As far as I can = see IA_PD is not linked to the M flag at all. There is no agreement on what the M and O bits do. Some people think M = means stateful address management; some think M means IA_NA and O means = IA_PD. RFC 4861 is actually fairly clear, at least to my reading of = it, that "M" means IA_NA and IA_PD, and that "O" means stateless DHCPv6, = but I've heard people argue vehemently that "M" means _only_ IA_NA, and = that "O" means IA_PD, because prefixes aren't addresses. So if you believe my reading of RFC 4861, you would set 'M' and expect = the HG to get both IA_NA and IA_PD; RFC 7084 makes it clear that = _either_ the 'M' or 'O' bit being set triggers the HG to do prefix = delegation. So if you want to do prefix delegation and not stateful address = assignment, set the 'O' bit and _not_ the 'M' bit, even though that = contradicts what RFC 4861 says. From sander@steffann.nl Tue Dec 10 08:55:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063331AE1D6; Tue, 10 Dec 2013 08:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s59oiiwM-Gyq; Tue, 10 Dec 2013 08:55:53 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id C34111AE171; Tue, 10 Dec 2013 08:55:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9592E3A; Tue, 10 Dec 2013 17:55:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqo4ee8hsauN; Tue, 10 Dec 2013 17:55:45 +0100 (CET) Received: from [100.91.63.199] (unknown [92.69.247.199]) by mail.sintact.nl (Postfix) with ESMTPSA id 0A18534; Tue, 10 Dec 2013 17:55:45 +0100 (CET) References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <07D76B96-3104-4781-A8BF-8FC072E50A3F@steffann.nl> X-Mailer: iPhone Mail (11B554a) From: Sander Steffann Date: Tue, 10 Dec 2013 17:55:45 +0100 To: Ted Lemon Cc: "v6ops@ietf.org" , "" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:55:55 -0000 Hi Ted, >> On Dec 10, 2013, at 6:08 AM, Sander Steffann wrote: >> As far as I know the M flag is linked only to IA_NA. As far as I can see I= A_PD is not linked to the M flag at all. >=20 > There is no agreement on what the M and O bits do. Some people think M m= eans stateful address management; some think M means IA_NA and O means IA_PD= . RFC 4861 is actually fairly clear, at least to my reading of it, that "M= " means IA_NA and IA_PD, and that "O" means stateless DHCPv6, but I've heard= people argue vehemently that "M" means _only_ IA_NA, and that "O" means IA_= PD, because prefixes aren't addresses. >=20 > So if you believe my reading of RFC 4861, you would set 'M' and expect the= HG to get both IA_NA and IA_PD; RFC 7084 makes it clear that _either_ the '= M' or 'O' bit being set triggers the HG to do prefix delegation. >=20 > So if you want to do prefix delegation and not stateful address assignment= , set the 'O' bit and _not_ the 'M' bit, even though that contradicts what R= FC 4861 says. What a mess... Sander From Ted.Lemon@nominum.com Tue Dec 10 08:56:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33191ADF53 for ; Tue, 10 Dec 2013 08:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdwrYPsvB1gy for ; Tue, 10 Dec 2013 08:56:55 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1611ADF74 for ; Tue, 10 Dec 2013 08:56:48 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUqdHy/4/pXEKO4BpQPXeeXmeouOjrgg4@postini.com; Tue, 10 Dec 2013 08:56:43 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 546AF1B82CB for ; Tue, 10 Dec 2013 08:56:43 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4D9EB190043; Tue, 10 Dec 2013 08:56:43 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 08:56:42 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <96747494E3D74D41B20907035DB1E48DCFAB@MOPESMBX03.eu.thmulti.com> Date: Tue, 10 Dec 2013 11:56:36 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <1F909C1B-5BDD-4E3D-B750-D8EABC12DB78@nominum.com> References: <96747494E3D74D41B20907035DB1E48DCFAB@MOPESMBX03.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 - WPD-4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:56:57 -0000 On Dec 10, 2013, at 5:59 AM, Wuyts Carl = wrote: > If this statement is correct, I=92m totally lost. According to what I = read in RFC4861 and 3315. O=3D1 means =93other configuration=94 means = =93information-request=94 DHCPv6 messages i.s.o. solicit, meaning not = (allowed) to add stateful options (IA_INA/IA_PD options) ??? The statement is there as a compromise, which was discussed at length in = the working group, resulting from a lack of agreement on what the 'O' = bit means. It needs to be there, and is correct. It really doesn't = make any sense for an HG _not_ to do prefix delegation. From otroan@employees.org Tue Dec 10 09:15:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14D01AE037; Tue, 10 Dec 2013 09:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xaWmfVQ0jaq; Tue, 10 Dec 2013 09:15:15 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4C1AE136; Tue, 10 Dec 2013 09:15:15 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAGdLp1KQ/khN/2dsb2JhbABZgwe6KYEeFnSCJQEBBAF5BQsLRlcGiA8GwRMXjwUHgyGBEwSQMZl2gyo7 X-IronPort-AV: E=Sophos;i="4.93,865,1378857600"; d="asc'?scan'208";a="1970817" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 10 Dec 2013 17:15:09 +0000 Received: from dhcp-10-61-104-186.cisco.com (dhcp-10-61-104-186.cisco.com [10.61.104.186]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBAHF1PC024392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 17:15:05 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_4FFDB8B1-EF34-4974-A170-8652236A0321"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> Date: Tue, 10 Dec 2013 18:14:56 +0100 Message-Id: <8185CEF1-9037-4956-B37E-0CFAE5689316@employees.org> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1822) Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:15:17 -0000 --Apple-Mail=_4FFDB8B1-EF34-4974-A170-8652236A0321 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, >> As far as I know the M flag is linked only to IA_NA. As far as I can = see IA_PD is not linked to the M flag at all. >=20 > There is no agreement on what the M and O bits do. Some people think = M means stateful address management; some think M means IA_NA and O = means IA_PD. RFC 4861 is actually fairly clear, at least to my reading = of it, that "M" means IA_NA and IA_PD, and that "O" means stateless = DHCPv6, but I've heard people argue vehemently that "M" means _only_ = IA_NA, and that "O" means IA_PD, because prefixes aren't addresses. that's incorrect. there are no flags in the RA that indicates if prefix = delegation is available or not. prefix delegation is between routers, routers don't listen to RAs was = the rationale. > So if you believe my reading of RFC 4861, you would set 'M' and expect = the HG to get both IA_NA and IA_PD; RFC 7084 makes it clear that = _either_ the 'M' or 'O' bit being set triggers the HG to do prefix = delegation. a RFC6204 CPE must act as a requesting router and request IA_PD in all = cases. it may choose to request the IA_NA based on the M flag or it might do so = regardless, both approaches are fine. > So if you want to do prefix delegation and not stateful address = assignment, set the 'O' bit and _not_ the 'M' bit, even though that = contradicts what RFC 4861 says. no, that's not what these flags mean. cheers, Ole --Apple-Mail=_4FFDB8B1-EF34-4974-A170-8652236A0321 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSp0wQAAoJEFuJXizso86gY9gH/R4Rffwb9ZwM3jAhsYKcARbq +/SXRSxtcN57bbr8pznDxGNU16KOEhKPb0BekkVrV9ZKqnffcuNlkdlz1Pbrtw4F sDMK2Dq6XCGypatOfXhTmzAAdO8kLa6VtD75tnGVK99tPm1Li5A9rcgXUZqKmXPl PGUTV7p96Er29YTtqjr9UkabBw2SLk4zI9PxOENQPJiILPqRbwN+pYkqWrWstFZP WfQEnXN2Gd54Q2fj529X+c01gXaDA821BIKOiVRd+228jdb2a/Yemsng3wEmoYHD XnnbHLBxKGE6xNkTYPEFz82K6KRvC3/0UspwWK02V7nKcTAb9hM8xnmULwly72I= =Em8q -----END PGP SIGNATURE----- --Apple-Mail=_4FFDB8B1-EF34-4974-A170-8652236A0321-- From alexandru.petrescu@gmail.com Tue Dec 10 09:17:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85F71AE1D6; Tue, 10 Dec 2013 09:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN_BCXFfUQRY; Tue, 10 Dec 2013 09:17:14 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id F02571AE1C0; Tue, 10 Dec 2013 09:17:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBAHH8hl027036; Tue, 10 Dec 2013 18:17:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B68CC204921; Tue, 10 Dec 2013 18:17:24 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A6B2D2042C3; Tue, 10 Dec 2013 18:17:24 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBAHH1H1016405; Tue, 10 Dec 2013 18:17:08 +0100 Message-ID: <52A74C8D.3050302@gmail.com> Date: Tue, 10 Dec 2013 18:17:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Sander Steffann , Mikael Abrahamsson References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , "" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:17:17 -0000 Le 10/12/2013 12:08, Sander Steffann a écrit : > Hi Mikael, > > Op 10 dec. 2013, om 08:10 heeft Mikael Abrahamsson het volgende geschreven: > >> From RFC4861: >> >> M 1-bit "Managed address configuration" flag. When >> set, it indicates that addresses are available via >> Dynamic Host Configuration Protocol [DHCPv6]. >> >> I interpret this as M=1 means addresses are available via DHCPv6, that means IA_NA and/or IA_PD, one or both might be available. I don't really understand why you do not. What do you think the M flag means? Reading the above text seems to indicate that you think it has something to do with managing the CPE? > > As far as I know the M flag is linked only to IA_NA. As far as I can see IA_PD is not linked to the M flag at all. The IA_PD should be linked to a requirement that has to do more with Routers at the Edge in general, and just in particular to CPE. Any Router at the Edge that needs to self-configure has no cleaner[*] alternative to using DHCP-PD, in addition to DHCP and/or SLAAC for address. Examples of Routers at the Edge: CPE, homenet Routers, smartphone hotspots, Mobile Routers as deployed in e.g. vehicles, road-side units, etc. All could benefit from IA_PD. This requirement is surprisingly present in the IPv6 cellular hosts RFC (although this a Router), and surprisingly absent from the IPv6 Node Requirements RFC (although a Node could be a Host or a Router sometimes). Alex [*]: for some value for 'clean'. Alternatives include 64share, IPv6NAT, NPT, ND-PD, NAT64, 6to4, IPv6transition... > > Cheers, > Sander > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From owen@delong.com Tue Dec 10 09:37:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151231AE04C; Tue, 10 Dec 2013 09:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hp1osSVnxny; Tue, 10 Dec 2013 09:37:57 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 14CEC1ADF4F; Tue, 10 Dec 2013 09:37:57 -0800 (PST) Received: from [172.25.1.50] (itsaudcal312pc1.ics.usc.edu [68.181.189.124]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBAHUXrl031001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Dec 2013 09:30:34 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBAHUXrl031001 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386696635; bh=oiUy5sSjbOwX76oRPIf7OHo0pr0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nwsm0vzFWKtXy6g/6Jj19CW7NO/uWGnqRNdjag6+CMlFyigv8J6WI5vpXve3AS0yR jOnTCeNLd6/bL6XjSIgvm0L047vo7rG9dPQne9N5AjEP13pvoc2xRco253TcbjQApj G64UKPYxkFoaYk9EfDnIfnfHrlSRlEnFGmd14AL8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> Date: Tue, 10 Dec 2013 09:30:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 10 Dec 2013 09:30:35 -0800 (PST) Cc: "" , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:37:59 -0000 My understanding from reading the various documents is that M =3D IA_NA, = O=3D everything else. Further, if M=3D1, O doesn=92t really matter. In no case do I believe that M or O provide any indication about IA_PD. I agree that it makes no sense for an HG (among others) not to do IA_PD. Owen On Dec 10, 2013, at 8:51 AM, Ted Lemon wrote: > On Dec 10, 2013, at 6:08 AM, Sander Steffann = wrote: >> As far as I know the M flag is linked only to IA_NA. As far as I can = see IA_PD is not linked to the M flag at all. >=20 > There is no agreement on what the M and O bits do. Some people think = M means stateful address management; some think M means IA_NA and O = means IA_PD. RFC 4861 is actually fairly clear, at least to my reading = of it, that "M" means IA_NA and IA_PD, and that "O" means stateless = DHCPv6, but I've heard people argue vehemently that "M" means _only_ = IA_NA, and that "O" means IA_PD, because prefixes aren't addresses. >=20 > So if you believe my reading of RFC 4861, you would set 'M' and expect = the HG to get both IA_NA and IA_PD; RFC 7084 makes it clear that = _either_ the 'M' or 'O' bit being set triggers the HG to do prefix = delegation. >=20 > So if you want to do prefix delegation and not stateful address = assignment, set the 'O' bit and _not_ the 'M' bit, even though that = contradicts what RFC 4861 says. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Tue Dec 10 09:40:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFCE1ADF74; Tue, 10 Dec 2013 09:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgX1lduKY2oJ; Tue, 10 Dec 2013 09:40:28 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 586941ADF4F; Tue, 10 Dec 2013 09:40:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUqdSBlGvV0KAa6W4ggb0giuTQ+T61Bay@postini.com; Tue, 10 Dec 2013 09:40:23 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 966501B82DC; Tue, 10 Dec 2013 09:40:22 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8F26B190043; Tue, 10 Dec 2013 09:40:22 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 09:40:22 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Tue, 10 Dec 2013 12:40:18 -0500 Content-Transfer-Encoding: 7bit Message-ID: <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> To: Owen DeLong X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "" , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:40:29 -0000 On Dec 10, 2013, at 12:30 PM, Owen DeLong wrote: > In no case do I believe that M or O provide any indication about IA_PD. You should read RFC 7084 again, then. Standards say what they say, not what you think they should say! :) From otroan@employees.org Tue Dec 10 09:46:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE301AE091; Tue, 10 Dec 2013 09:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQvIuUc0dqqZ; Tue, 10 Dec 2013 09:46:35 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 83D5F1ADF74; Tue, 10 Dec 2013 09:46:09 -0800 (PST) Received: from dhcp-10-61-107-239.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 418F45FAD; Tue, 10 Dec 2013 09:45:25 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_A6998C43-A043-41BF-B4C5-E81F3227A474"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> Date: Tue, 10 Dec 2013 18:44:44 +0100 Message-Id: <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1822) Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:46:37 -0000 --Apple-Mail=_A6998C43-A043-41BF-B4C5-E81F3227A474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> In no case do I believe that M or O provide any indication about = IA_PD. >=20 > You should read RFC 7084 again, then. >=20 > Standards say what they say, not what you think they should say! :) RFC7084 isn't a standard. can we please stop this now. having the M/O debate one more time is = unlikely to provide a different result than the previous times we have = had this debate. Ole --Apple-Mail=_A6998C43-A043-41BF-B4C5-E81F3227A474 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSp1MMAAoJEFuJXizso86gV1gH/0YiYIY7vyzuEsxU8tCvhx7N vsAyJ28PSPHO0xhcILQHLZIMY9eYXDn46UZPRLFEZe3qr8vBVB0Usk3iglnGlyB9 +V3mMi+OEKbykIjBSzh2OXOe3Iox1ZISowidzr7StHu+4XJwiigzthp1MCckI9n9 AXBE0sQnUuvVjiiPH1A2seUma7jr6OFhKoilMqEgXQp5X8HoYydetOSeNdqr0aEC gmCwuMwL+T+q9LXM1Tv/uio9scr/S9NETqyzoovzfAiZCupyZlCU2149ac3nSy5n L9mrprQvfASwM0iC87+d9kgPE/4TZB7vOQnCV4H1W4ohSQu8Q5DgEc1mfYJBt4Y= =QRUB -----END PGP SIGNATURE----- --Apple-Mail=_A6998C43-A043-41BF-B4C5-E81F3227A474-- From sarikaya2012@gmail.com Tue Dec 10 12:03:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E481AE17E for ; Tue, 10 Dec 2013 12:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RI2Nfm-IRjB for ; Tue, 10 Dec 2013 12:03:09 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 436341AE0E6 for ; Tue, 10 Dec 2013 12:03:09 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id eo20so3088111lab.0 for ; Tue, 10 Dec 2013 12:03:03 -0800 (PST) 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=kfoL/mTuW7rtTD7PUDWKFU9dAeUnRMUhOihWMi8P7sw=; b=p0lpcxXKdI2OkSzwx4MwEQ/MtL2FonafhgAuBk8XP3O2Dm7k6cGW9PN1m7AOsg5wUi /Z6oYGHB6y23yL1gAIgfz6n7/akkG73U7w4L7RhaQmDOFbPSohLdTHDq5zIN1tMyQ23N QApj9hUHZY4pcXEsaxbApJcDU3c6z0ZYRGHJ/U4NJIljEdzyQvuFpUFF0+t2L/cTIOc4 KHGA/q52m+ktFPDKPRoaZSfoQlHkRh1Ef9lkD3WwXLnqz+OOB5pDsxCd9EwTMlVLMgze Luf9rpa9+ztsvqFTHE2nO14Wrbdgo9GDzp0a010a3+jqyNInfiHGpqHsEI9sjjEpcg4q tC4w== MIME-Version: 1.0 X-Received: by 10.152.116.46 with SMTP id jt14mr9295912lab.31.1386705783263; Tue, 10 Dec 2013 12:03:03 -0800 (PST) Received: by 10.115.4.165 with HTTP; Tue, 10 Dec 2013 12:03:03 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D823D27@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D823D27@nkgeml506-mbx.china.huawei.com> Date: Tue, 10 Dec 2013 14:03:03 -0600 Message-ID: From: Behcet Sarikaya To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c356249e974604ed3399ea Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 20:03:11 -0000 --001a11c356249e974604ed3399ea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Bing, My suggestion is requirements on delivering routes to the hosts also > should be added to this draft. > > [Bing] I=92m not sure, because there hasn=92t been DHCP-based routes > delivering mechanism, so there hasn=92t been interaction problems so far. > Yes, it did, it happened in mif WG, maybe that's why you are not familiar. You can check mif mailing list archive and minutes, please check IETF 83 minutes here: http://tools.ietf.org/wg/mif/minutes?item=3Dminutes-83-mif.html Regards, Behcet > Maybe we could consider this issue in the future. > > Best regards, > > Bing > > Regards, > > Behcet > > > > On Wed, Dec 4, 2013 at 7:45 AM, wrote: > > > A new draft has been posted, at > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Please > take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > --001a11c356249e974604ed3399ea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Bing,



My= suggestion is requirements on delivering routes to the hosts also should b= e added to this draft.

[Bing] I=92m not sure, because there hasn= =92t been DHCP-based routes delivering mechanism, so there hasn=92t been in= teraction problems so far.


Yes, it did, it happened in mif WG, maybe that's= why you are not familiar.
You can check mif mailing list arc= hive and minutes, please check IETF 83 minutes here:

http://tools.ietf.org/wg/mif/minutes?item=3Dminutes-83-mif.html

Regards,

Behcet

Maybe we could consider this issue= in the future.

Best regards,

Bing

Re= gards,

Behcet

=A0

On Wed, Dec 4, 2013 at 7:45 AM,= <fred@cisco.com= > wrote:


A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Pleas= e take a look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

=A0


--001a11c356249e974604ed3399ea-- From leo.liubing@huawei.com Tue Dec 10 18:11:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02CE1AE0AD for ; Tue, 10 Dec 2013 18:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIqCVulqoERf for ; Tue, 10 Dec 2013 18:11:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E20371AC829 for ; Tue, 10 Dec 2013 18:11:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYV98180; Wed, 11 Dec 2013 02:11:36 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 02:11:26 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 02:11:34 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 10:11:31 +0800 From: "Liubing (Leo)" To: "sarikaya@ieee.org" Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO8PcjWuMJf8I9f0eBAQAUd5rlEZpLkRkAgAFqd6CAAGIQgIAA5FYw Date: Wed, 11 Dec 2013 02:11:30 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D824132@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D823D27@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D824132nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 02:11:47 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D824132nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Behcet From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Wednesday, December 11, 2013 4:03 AM To: Liubing (Leo) Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Hi Bing, My suggestion is requirements on delivering routes to the hosts also should= be added to this draft. [Bing] I'm not sure, because there hasn't been DHCP-based routes delivering= mechanism, so there hasn't been interaction problems so far. Yes, it did, it happened in mif WG, maybe that's why you are not familiar. [Bing] Yes, I noticed your mentioning about the draft-ietf-mif-dhcpv6-route= -option-05 in a previous mail to Andrew Yourtchenko. I do agree this point is regarding with RA/DHCP comparison/overlapping. But= for draft-ietf-v6ops-dhcpv6-slaac-problem, I have two considerations: 1. I guess there hasn't been implementation for the DHCP-based routes = mechanism yet? So it's hard to say whether there would be problems. 2. It might not be really essential to the draft. The DHCPv6 routes op= tion could be considered as one instance of "Otherconfig" as hinted by the = O flag in RA. The draft focuses on whether the hosts would do "Otherconf" o= r not when they interpreting the O flag in various conditions. For what the= "otherconfig" might be, DNS or routes, it should not be the scope of the d= raft as I understand. You can check mif mailing list archive and minutes, please check IETF 83 mi= nutes here: http://tools.ietf.org/wg/mif/minutes?item=3Dminutes-83-mif.html [Bing] I was a really long discussion :) But interesting and valuable, tha= nks for sharing. Best regards, Bing Regards, Behcet Maybe we could consider this issue in the future. Best regards, Bing Regards, Behcet On Wed, Dec 4, 2013 at 7:45 AM, > wro= te: A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops= -dhcpv6-slaac-problem. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D824132nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Behcet<= o:p>

 = ;

From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Sent: Wednesday, December 11, 2013 4:03 AM
To: Liubing (Leo)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-proble= m

 

= Hi Bing,

=  

My suggestion is requirements on delivering routes = to the hosts also should be added to this draft.

[Bing] I’m not sure, bec= ause there hasn’t been DHCP-based routes delivering mechanism, so there hasn’t been interaction problems so far.

 

Yes, it did, it happened in mif= WG, maybe that's why you are not familiar.

[Bing] Yes= , I noticed your mentioning about the draft-ietf-mif-dhcpv6-route-option-05= in a previous mail to Andrew Yourtchenko.

I do agree= this point is regarding with RA/DHCP comparison/overlapping. But for draft= -ietf-v6ops-dhcpv6-slaac-problem, I have two considerations:

1.      I = guess there hasn’t been implementation for the DHCP-based routes mech= anism yet? So it’s hard to say whether there would be problems.

2.      It= might not be really essential to the draft. The DHCPv6 routes option could= be considered as one instance of “Otherconfig” as hinted by the O flag in RA. The draft focuses on whether the hosts would do ̶= 0;Otherconf” or not when they interpreting the O flag in various cond= itions. For what the “otherconfig” might be, DNS or routes, it = should not be the scope of the draft as I understand.

 = ;

= You can check mif mailing list archive and minutes, please check IETF 83 mi= nutes here:

http://tools.ietf.org/wg/mif/minutes?item=3Dminutes-83-mif.html
[Bing] I was a really long discussion = J=  But interesting = and valuable, thanks for sharing.

Best regards,

Bing

 

= Regards,

Behcet

Maybe we could consider this i= ssue in the future.

Best regards,

Bing

Regards,

Behcet

 

On Wed, Dec 4, 2013 at 7:45 AM, <fred@cisco.com> wrote:<= o:p>


A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Pleas= e take a look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

 

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D824132nkgeml506mbxchi_-- From dwing@cisco.com Tue Dec 10 19:05:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F8B1AE339 for ; Tue, 10 Dec 2013 19:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGtL3peEmSw5 for ; Tue, 10 Dec 2013 19:05:35 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A57851AE33A for ; Tue, 10 Dec 2013 19:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6445; q=dns/txt; s=iport; t=1386731130; x=1387940730; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rutY8dvFYoCrpl3kkuL4cT8YtFFNb53haYtgQkLQmT8=; b=nA38GHczvUljh15pHcUS/Y/Jo4dnb0RrOQFnhV4sleQK8gJycqTFWGQf lG7YBhlwjlZ8JnXhzZQaFgPXbET59tleUR5klrsZuQq02jP89QsiQzLTN j4a6WFlJ1FMWfOOsyCJebw8c9EhCzwLb0pR9vI3wimcKwJ2RQNpNPKZUi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAG/Vp1KrRDoG/2dsb2JhbABZgwc4TbkngSAWdIIlAQEBAwEBAQE3KwIHCwULC0YhBjAGEwmHZwMJBQkFulMNhmcXjHOBMBEBHTMHgyGBEwSJQopvgXiBa4EwiyqFOYFrgV8bgTU X-IronPort-AV: E=Sophos;i="4.93,869,1378857600"; d="scan'208";a="97565129" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Dec 2013 03:05:30 +0000 Received: from sjc-vpn4-667.cisco.com (sjc-vpn4-667.cisco.com [10.21.82.155]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBB35RxG003128; Wed, 11 Dec 2013 03:05:28 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Tue, 10 Dec 2013 19:05:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: GangChen X-Mailer: Apple Mail (2.1510) Cc: v6ops Subject: Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 03:05:39 -0000 On Dec 8, 2013, at 7:48 PM, GangChen wrote: > Wg, >=20 > We have submitted the new version of NAT64 Operational Experience. > The updates are summarized as follows: >=20 > 1) Clarify the case when NAT64 serves as the IPv6 gateway ( Sec. = 3.1.2) > 2) Polish the statement of NAT44 & NAT64 co-existing (Sec. 3.1.4) > 3) Clarify that the sub-domain configuration is only for the > experimental phase (Sec 3.2) > 4) Share the data for the scale of sync data in hot standby (Sec 4.1) > 5) Assessing the Impact of NAT64 to applications (Sec. 6.1) >=20 > Your further reviews/comments are welcome. draft-ietf-v6ops-nat64-experience-05 reads, in part: "6.1. Service Reachability NAT64 is providing a translation capability between IPv6 and IPv4 end-nodes. In order to provide the reachability between two IP address families, NAT64-CGN has to implement appropriate application aware functions, i.e. Application Layer Gateway (ALG), where address translation is not itself sufficient and security mechanisms do not render it infeasible. Most NAT64-CGNs mainly provide FTP- ALG[RFC6384]. NAT64-FEs may have functional richness on Load Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have been supported." Can some text be added describing what an HTTP-ALG, HTTPS-ALG, RTSP-ALG, = and SMTP-ALG might do? For HTTP, HTTPS, and maybe RTSP, I guess it adds = a Via or X-Forwarded-For so the IPv4 host can get visibility to the = original IPv6 address? (I'm not sure.) For SMTP-ALG, I can't guess = what it might do -- add a Received: header, or modify the EHLO/HELO = exchange? Later in the table, it reads: Instance Message|Mostly fail, softwares don't support IPv6 =20= I think it should be "instant messenger". It seems important to point = out, in the document, that the lack of IPv6 support is not the fault or = cause of NAT64 technology. Rather, the lack of IPv6 support prevents = those applications from working on an IPv6-only host or working over = IPv6 on a dual-stack host -- that is, they are stuck being IPv4-only = applications. The only thing that will help them is 464xlat, which = should be pointed out in the document. Then for games it says: | Games |Mostly pass for web-based games and mostly fail for = | | |standalone games due to software supports Is "due to software supports" the same as "softwares don't support = IPv6", or is the different phrasing describing an important difference? | Email | Pass = | Is that IMAP, POP, SMTP, or all? Is that with, or without, SMTP-ALG? | VoIP | Fail, due to the lack of SIP-ALG support on NAT64 = | There certainly are non-SIP VoIP applications -- XMPP for example, and = proprietary systems like Skype. If only SIP was tested, say "SIP". = Furthermore, if the SIP endpoint supports ICE, SIP-ALG is unnecessary, = and any successful Internet deployment of a SIP client does need to = support ICE. This particular case needs to be tightened up in the = document. | VPN | Fail, due to incapability of IPsec verification = | So, this was IPsec VPN, and not "SSL" VPN. That should be clarified in = the document. What is "incapability of IPsec verification"? I know the = issue you are no doubt referring to, but that could be solved in IPsec = implementations should they be inclined - but nobody has documented the = problem yet. Did you try IPsec-over-UDP or IPsec-over-TCP, and did = those also fail? If IPsec native (protocol 50), I guess the CGN-NAT64 = had support for IPsec Passthru which is a defacto standard (but not = documented, and has some issues with SPI changing). In regard to the widespread applications of VoLTE in the near future, SIP-ALG is of great value to be implemented on NAT64-CGN. I whole-heartedly disagree with that sentence. We should be encouraging = RFC6157 ("IPv6 Transition in the Session Initiation Protocol (SIP)") not = the proliferation of application layer gateways. Application layer = gateways are buggy (as is all software) and cause interoperation = problems, interfere with deployment of new services, and a myriad of = other problems. Their time has come and gone, let's bid ALG farewell = and have applications be responsible for their proper function on the = network, rather than the network trying to 'help' the applications. -d >=20 > BRs >=20 > Gang >=20 > 2013/12/9, internet-drafts@ietf.org : >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >>=20 >> Title : NAT64 Operational Experience >> Author(s) : Gang Chen >> Zhen Cao >> Chongfeng Xie >> David Binet >> Filename : draft-ietf-v6ops-nat64-experience-05.txt >> Pages : 21 >> Date : 2013-12-08 >>=20 >> Abstract: >> This document summarizes NAT64 function deployment scenarios and >> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) = and >> NAT64 server Front End (NAT64-FE) are considered in this document. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-05= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Tue Dec 10 22:22:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6A31AE0BA; Tue, 10 Dec 2013 22:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL5fUAp8bgze; Tue, 10 Dec 2013 22:22:06 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9B75E1AD937; Tue, 10 Dec 2013 22:22:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUqgEiRxzHXACpxbcStw4mqx93fG7baDP@postini.com; Tue, 10 Dec 2013 22:22:01 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 28C081B82E3; Tue, 10 Dec 2013 22:22:01 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0823F190043; Tue, 10 Dec 2013 22:22:01 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 22:22:00 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <8185CEF1-9037-4956-B37E-0CFAE5689316@employees.org> Date: Wed, 11 Dec 2013 01:21:58 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <731AA5B7-427D-4A2C-B90E-F5A46B7C1017@nominum.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <8185CEF1-9037-4956-B37E-0CFAE5689316@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 06:22:09 -0000 On Dec 10, 2013, at 12:14 PM, Ole Troan wrote: > that's incorrect. there are no flags in the RA that indicates if = prefix delegation is available or not. prefix delegation is between = routers, routers don't listen to RAs was the rationale. It's certainly true that RFC 4861 doesn't mention prefix delegation, and = this is a plausible rationale for not doing so. However, the HG is = clearly a router, and it's being required to listen to RAs, so the = distinction you are making is _extremely_ artificial.= From alexandru.petrescu@gmail.com Wed Dec 11 01:45:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570661A1F4E; Wed, 11 Dec 2013 01:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcwvuKRvDsVA; Wed, 11 Dec 2013 01:45:46 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 208B61A1F06; Wed, 11 Dec 2013 01:45:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBB9jaoY014357; Wed, 11 Dec 2013 10:45:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C2E1C204BE7; Wed, 11 Dec 2013 10:45:53 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B2E0A204BE2; Wed, 11 Dec 2013 10:45:53 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBB9jWVL031826; Wed, 11 Dec 2013 10:45:36 +0100 Message-ID: <52A8343C.3040202@gmail.com> Date: Wed, 11 Dec 2013 10:45:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ole Troan , Ted Lemon References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> In-Reply-To: <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 09:45:48 -0000 Le 10/12/2013 18:44, Ole Troan a écrit : >>> In no case do I believe that M or O provide any indication about >>> IA_PD. >> >> You should read RFC 7084 again, then. >> >> Standards say what they say, not what you think they should say! >> :) > > RFC7084 isn't a standard. can we please stop this now. having the M/O > debate one more time is unlikely to provide a different result than > the previous times we have had this debate. I agree we should go past the typical M/O debate, learn from it. One way I read the ongoing discussion, if I am not wrong, is that there is difficulty created by the lack of a flag specific to IA_PD ("As far as I know the M flag is linked only to IA_NA. As far as I can see IA_PD is not linked to the M flag at all."). Am I the only to read this as maybe a hint towards necessity of creation of a new flag akin to M/O but specific to IA_PD? I.e. it would be allow a Router to see whether it may be able to specifically request a Delegated Prefix even when it would self-configure its address by other means than DHCP. (in the past some local thought was given about how RA would advertise a capability of delegating prefixes, e.g. this 'D' flag in a draft: > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Cur Hop Limit |M|O|H|Prf|P|D|r| Router Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ) Alex > > Ole > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From ek@google.com Wed Dec 11 02:09:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DD31AD935 for ; Wed, 11 Dec 2013 02:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWq5FifGuBRI for ; Wed, 11 Dec 2013 02:09:12 -0800 (PST) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id DDFBD1AE06D for ; Wed, 11 Dec 2013 02:09:10 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id j5so420572qaq.19 for ; Wed, 11 Dec 2013 02:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nLXQ3TF5urWRuRsbGk3eJYe+UqZOfTsi67VPEGUHXZI=; b=RndHICWEqK0GKr5zWjByrOENT1j7uxYJP7QpBXJUE78/LEqaTR+joPrwcyh2/i8/+q AnqgRz0dw7+/41iPxcMJdaaGf9IJ9N0GufNlKz8AjFphtTx79orxJ4Inwh5I+C4LQ73B 3F4002ib7wQWHxyjISRvnF+OmFTpV2JEpwWKdATmWlnukXxnDutzDIc9jiVw1lIr284D ucOkMOC9vhJ267FmsE5PDPIAajGBXZjVhBPdxEf8iEdK34UNFEEPG0TJiw+98xwg8FsX +A4fW6w8I+tyDR1imlPNwdVUlkCP526ib6yPT0Hh7AHrUtznbbhFss+3GxR2f2vTlHZu PY7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nLXQ3TF5urWRuRsbGk3eJYe+UqZOfTsi67VPEGUHXZI=; b=HhAOcDD704NkH7TGEuVMAj7oMH2SLZa9jXK/xRKIpMg3c2DS8tlS6kdLAJvmCsOPm1 UJwu88X8h2gDVlIHZt8XQWUa+lRlboJAHhZmgfvC8LAIMj6NvV1ugySCTUVhXIicq46a 2iBa+juRoyrevuxCvF3V/A6WIXVK4hJxCY2rH9htlfAAJkrxh/XCn6Spg2Ia6g637s5e DddZUGCIPKrGEY0fnVH3Te34ZdbWjzYKMblJtIWg65s1c4Lbrk6o4T3U1pt6sIb7TAYx ztjcsLaoJjScaXTg/yC3Q58txx+LMWU42PpTvsrIyj1b4G+nA4j8kiudHZGDGjEDXSvt h22g== X-Gm-Message-State: ALoCoQk5b2GWVU8eNH8OWnNcI77ysUTEKFTGTha7vkwMT/d7hwy6N9RQrsXXUk+qDm2miTRrYijcZhrRoDmQM8T5bh9VnnwNS2V9Ht9Pv+EurDv36iTIvsyXLWGFhlI9d1VFMLvtWPaOFl96Sel/iPWa3knkkE2zTIcTGTWbmFPCuDGgNgj5ACgog8ao3r5SRGZxL+bSs8Dp X-Received: by 10.49.15.104 with SMTP id w8mr871705qec.49.1386756544479; Wed, 11 Dec 2013 02:09:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.26.8 with HTTP; Wed, 11 Dec 2013 02:08:44 -0800 (PST) In-Reply-To: <52A8343C.3040202@gmail.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> From: Erik Kline Date: Wed, 11 Dec 2013 19:08:44 +0900 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 10:09:13 -0000 > Am I the only to read this as maybe a hint towards necessity of creation > of a new flag akin to M/O but specific to IA_PD? I.e. it would be allow > a Router to see whether it may be able to specifically request a > Delegated Prefix even when it would self-configure its address by other > means than DHCP. I'm not sure I understand how's that materially different/better than a node just trying to request a PD if it wants one, and coping with the response (whatever it may be), like it does today. I think at best you'd end up saving a few unnecessary packets per device per uptime cycle. From alexandru.petrescu@gmail.com Wed Dec 11 02:21:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6594A1AD937; Wed, 11 Dec 2013 02:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAZdW9TkKDKY; Wed, 11 Dec 2013 02:21:25 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 158BD1AD8DB; Wed, 11 Dec 2013 02:21:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBBALFnE029150; Wed, 11 Dec 2013 11:21:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D7554204C51; Wed, 11 Dec 2013 11:21:32 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BA6D5204C2A; Wed, 11 Dec 2013 11:21:32 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBBAL69k027814; Wed, 11 Dec 2013 11:21:15 +0100 Message-ID: <52A83C92.4020204@gmail.com> Date: Wed, 11 Dec 2013 11:21:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Erik Kline References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 10:21:27 -0000 Le 11/12/2013 11:08, Erik Kline a écrit : >> Am I the only to read this as maybe a hint towards necessity of >> creation of a new flag akin to M/O but specific to IA_PD? I.e. it >> would be allow a Router to see whether it may be able to >> specifically request a Delegated Prefix even when it would >> self-configure its address by other means than DHCP. > > I'm not sure I understand how's that materially different/better > than a node just trying to request a PD if it wants one, and coping > with the response (whatever it may be), like it does today. Well, as you suggest below, it may save some bytes on the wire, i.e. would not send the expensive Solicit if the preceding RA said no PD available. I suppose this is the same reason of presence of other flags in the RA, like the H (HMIPv6) and P (PMIPv6). Alex > I think at best you'd end up saving a few unnecessary packets per > device per uptime cycle. > > From v6ops@globis.net Wed Dec 11 03:25:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6070F1AC862; Wed, 11 Dec 2013 03:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8tpS2uBkFsv; Wed, 11 Dec 2013 03:25:13 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 70E921AC82B; Wed, 11 Dec 2013 03:25:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6567E87145B; Wed, 11 Dec 2013 12:25:06 +0100 (CET) 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 4xDGD9XceIJF; Wed, 11 Dec 2013 12:25:06 +0100 (CET) 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 298BD870F98; Wed, 11 Dec 2013 12:25:06 +0100 (CET) Message-ID: <52A84B91.1000106@globis.net> Date: Wed, 11 Dec 2013 12:25:05 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Ted Lemon References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <8185CEF1-9037-4956-B37E-0CFAE5689316@employees.org> <731AA5B7-427D-4A2C-B90E-F5A46B7C1017@nominum.com> In-Reply-To: <731AA5B7-427D-4A2C-B90E-F5A46B7C1017@nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:25:14 -0000 Ted Lemon wrote: > On Dec 10, 2013, at 12:14 PM, Ole Troan wrote: >> that's incorrect. there are no flags in the RA that indicates if prefix delegation is available or not. prefix delegation is between routers, routers don't listen to RAs was the rationale. > > It's certainly true that RFC 4861 doesn't mention prefix delegation, and this is a plausible rationale for not doing so. However, the HG is clearly a router, and it's being required to listen to RAs, so the distinction you are making is _extremely_ artificial. Actually I happen to think the distinction between labeling a _device_ as a "router" or an "end node" is itself artificial. There are plenty of functions where a typical CPE device has to function as an end node (basically for anything where it is terminating traffic). I think it would be better to make the distinction between "router" and "end node" based on whether the _traffic_ is being forwarded by the device or terminated on the device. Then for PD and SLAAC autoconfig you would have an end node that could learn a default route or upstream interface GUA prefix via RA, and more specific information via a routing protocol. -- Regards, RayH From phdgang@gmail.com Wed Dec 11 07:04:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5A81ADF60 for ; Wed, 11 Dec 2013 07:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIIdtXalJmS3 for ; Wed, 11 Dec 2013 07:04:19 -0800 (PST) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CB5961ADED6 for ; Wed, 11 Dec 2013 07:04:18 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id t7so5279377qeb.6 for ; Wed, 11 Dec 2013 07:04:13 -0800 (PST) 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; bh=2jAXaL9kUi3CAjW9H0JVYMv98GnImzyyIcDhEnRYORg=; b=L+nryJ7dEwTZn+XPm2qXa7FWnp/z+DpGSWPongrk2MgCmJJjxokd1Uk2MvEcpSLSu4 cHXmACEzqRlG1MQW8wa+eYnXrftztxA1JrgPTcgbFReoOMOw74z6ayqYC7+7KjYIed9P gKfEDdn0MtnWIIHM66TO3ckAiXsviGEMkbJsFz9FO/lRweRzsG5ENJMfQd1Q9CKRT0fM iQe0N8E+l0ytvruXiwc5lRi3Qz9W3pU7/ZcrNKCKR7gC+AW7pxCrXus7QNfwLMGDSfwJ 5f1bf6xZZfn+BKQO9mcc+7JEVyHhjGzO+ab+87mRTkrCA8ugYLYdoNj3gClYIWkX775o 7IDw== MIME-Version: 1.0 X-Received: by 10.224.20.202 with SMTP id g10mr3515561qab.66.1386774253066; Wed, 11 Dec 2013 07:04:13 -0800 (PST) Received: by 10.224.172.135 with HTTP; Wed, 11 Dec 2013 07:04:13 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Dec 2013 23:04:13 +0800 Message-ID: From: GangChen To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:04:22 -0000 Thank you for the useful comments. Please see my reply inline. 2013/12/11, Dan Wing : > > On Dec 8, 2013, at 7:48 PM, GangChen wrote: > >> Wg, >> >> We have submitted the new version of NAT64 Operational Experience. >> The updates are summarized as follows: >> >> 1) Clarify the case when NAT64 serves as the IPv6 gateway ( Sec. 3.1.2) >> 2) Polish the statement of NAT44 & NAT64 co-existing (Sec. 3.1.4) >> 3) Clarify that the sub-domain configuration is only for the >> experimental phase (Sec 3.2) >> 4) Share the data for the scale of sync data in hot standby (Sec 4.1) >> 5) Assessing the Impact of NAT64 to applications (Sec. 6.1) >> >> Your further reviews/comments are welcome. > > draft-ietf-v6ops-nat64-experience-05 reads, in part: > > "6.1. Service Reachability > > NAT64 is providing a translation capability between IPv6 and IPv4 > end-nodes. In order to provide the reachability between two IP > address families, NAT64-CGN has to implement appropriate application > aware functions, i.e. Application Layer Gateway (ALG), where address > translation is not itself sufficient and security mechanisms do not > render it infeasible. Most NAT64-CGNs mainly provide FTP- > ALG[RFC6384]. NAT64-FEs may have functional richness on Load > Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have > been supported." > > Can some text be added describing what an HTTP-ALG, HTTPS-ALG, RTSP-ALG, and > SMTP-ALG might do? For HTTP, HTTPS, and maybe RTSP, I guess it adds a Via > or X-Forwarded-For so the IPv4 host can get visibility to the original IPv6 > address? (I'm not sure.) For SMTP-ALG, I can't guess what it might do -- > add a Received: header, or modify the EHLO/HELO exchange? Depending on the tests, ALGs detect and change following filed: For HTTP, HTTPs, the IP address inserted in the Via filed For RTSP, the "dest_addr" and "src_addr" in SETUP message For SMTP, some mail message for trace purpose insert the IP address in the "Received: " field or "Mail From: " To describe what those ALGs might do, the follows texts will be added for the clarification: "NAT64-FEs may have functional richness on Load Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have been supported. Those application protocols exchange IP address and port parameters within control session, for example the "via" filed in a HTTP header, "transport" field in a RTSP SETUP message and "Received: " header in SMTP message. ALG functions will detect those fields and make IP address translations." > > Later in the table, it reads: > > Instance Message|Mostly fail, softwares don't support IPv6 > > I think it should be "instant messenger". It seems important to point out, > in the document, that the lack of IPv6 support is not the fault or cause of > NAT64 technology. Rather, the lack of IPv6 support prevents those > applications from working on an IPv6-only host or working over IPv6 on a > dual-stack host -- that is, they are stuck being IPv4-only applications. > The only thing that will help them is 464xlat, which should be pointed out > in the document. Agree. We will clarify the meaning. > > Then for games it says: > > | Games |Mostly pass for web-based games and mostly fail for | > | |standalone games due to software supports > > Is "due to software supports" the same as "softwares don't support IPv6", or > is the different phrasing describing an important difference? Same meaning with "softwares don't support IPv6"" > > | Email | Pass | > > Is that IMAP, POP, SMTP, or all? Is that with, or without, SMTP-ALG? We test POP and SMTP. SMTP-ALG is supported > > > | VoIP | Fail, due to the lack of SIP-ALG support on NAT64 | > > There certainly are non-SIP VoIP applications -- XMPP for example, and > proprietary systems like Skype. If only SIP was tested, say "SIP". > Furthermore, if the SIP endpoint supports ICE, SIP-ALG is unnecessary, and > any successful Internet deployment of a SIP client does need to support ICE. > This particular case needs to be tightened up in the document. We mainly test SIP-VoIP applications as below stated. I will notice this information in the table. The test is made based on 4G mobile environment. The ICE function is not available at the mobile device side yet at this time. Your comments are useful, because I didn't realize it should be recommended to make use of ICE other than implementing ALG on the NAT64 box. I will update this row as | SIP-VoIP | Fail, due to the lack of SIP NAT64 traversal | Some additional descriptions will be added as below (*) > > | VPN | Fail, due to incapability of IPsec verification | > > So, this was IPsec VPN, and not "SSL" VPN. That should be clarified in the > document. What is "incapability of IPsec verification"? I know the issue > you are no doubt referring to, but that could be solved in IPsec > implementations should they be inclined - but nobody has documented the "incapability of IPsec verification" means the remote peer would invalidate the packet since NAT64 changes the header and IPsec-AH likely detect the change. For IPsec ESP,NAT64 can't update the TCP/UDP checksum, which is encrypted. The remote peer is failed to validate the received packages. We will update the row as | VPN | Fail for IPsec-based VPN, the translated IPsec packages are invalidated | Would it be helpful if we also add above statement into the draft? > problem yet. Did you try IPsec-over-UDP or IPsec-over-TCP, and did those > also fail? If IPsec native (protocol 50), I guess the CGN-NAT64 had support TCP/UDP is failed due to above reason. > for IPsec Passthru which is a defacto standard (but not documented, and has > some issues with SPI changing). The tested NAT64 can't support this function. So I can't say more on this point. Your suggestion would be appreciated. > > In regard to the widespread applications > of VoLTE in the near future, SIP-ALG is of great value to be > implemented on NAT64-CGN. > > I whole-heartedly disagree with that sentence. We should be encouraging > RFC6157 ("IPv6 Transition in the Session Initiation Protocol (SIP)") not the > proliferation of application layer gateways. Application layer gateways are > buggy (as is all software) and cause interoperation problems, interfere with > deployment of new services, and a myriad of other problems. Their time has > come and gone, let's bid ALG farewell and have applications be responsible > for their proper function on the network, rather than the network trying to > 'help' the applications. (*)Really great comments. I incorporate your comments and try to make following changes: ===OLD=== For VoIP services, we mainly tested Voice over LTE services[IR.92], which is the major solution for voice in the fourth generation communication ages. NAT64 is testified with some issues of SIP-ALG supports. In regard to the widespread applications of VoLTE in the near future, SIP-ALG is of great value to be implemented on NAT64-CGN. ===New=== For SIP-VoIP services, we mainly tested Voice over LTE services[IR.92], which is the major solution for voice in the fourth generation mobile communication age. The voice call is failed due to the lack of NAT64 traveral when an IPv6 SIP user agent communicates with an IPv4 SIP user agent. The Interactive Connectivity Establishment (ICE) described in [RFC5245]is recommended to be supported as the NAT64 traveral mechanism during the SIP IPv6 transition. Required functions should be implemented at SIP client side(e.g. mobile device), and STUN relay server and STUN server should be deployment. [RFC6157] describes both signalling and media layer process, which should be followed. BRs Gang > -d > > > > > > > > >> >> BRs >> >> Gang >> >> 2013/12/9, internet-drafts@ietf.org : >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IPv6 Operations Working Group of the >>> IETF. >>> >>> Title : NAT64 Operational Experience >>> Author(s) : Gang Chen >>> Zhen Cao >>> Chongfeng Xie >>> David Binet >>> Filename : draft-ietf-v6ops-nat64-experience-05.txt >>> Pages : 21 >>> Date : 2013-12-08 >>> >>> Abstract: >>> This document summarizes NAT64 function deployment scenarios and >>> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and >>> NAT64 server Front End (NAT64-FE) are considered in this document. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-05 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From ietf@rozanak.com Wed Dec 11 07:56:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9821ADF5F; Wed, 11 Dec 2013 07:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I87Nd3Ltp-CA; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0121ADC03; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MUp6q-1W2zUv3QoG-00YriV; Wed, 11 Dec 2013 10:56:50 -0500 From: "Hosnieh Rafiee" To: , , , References: In-Reply-To: Date: Wed, 11 Dec 2013 16:56:41 +0100 Message-ID: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CEF691.FB7F0720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac72iSvPgVYgbXT9Tp2rb9e4S1H5BQAABB3g Content-Language: en-us X-Provags-ID: V02:K0:zsorZVhW8HgeflfAdkqx44XEhAz1ybLvxGiEIOStOdR l6APmNSpArup54roxvO9Uil1wRt+vU2S8n5NF1qF2IZvqk9Urn 8+zdGx8jNCUMNu+jibJdw9ekKma8VAmZiEv4xBVQiSoEt5odYs 8+lqvf5E0supOsi8Cg3PsJ17ki+OfTmOzzDdPJUXyaa6ofnfy4 b7E16COcPOxjWS1Rfxi7JypZv7WKu96HJrB3L/k2K+ADOmr/u6 a+XNj0mY4xcXCqvKwJAPc4RHfHikBps5GLzWWJBatVoqfzW+JN dzgpMURtRaqsMwVc0Da//ZBinNwv0QGMi+U/S8QCQ1tDIQ+mtU q3lmcZ2n6HT80UoXWwaI= Subject: [v6ops] new mailing list in security area X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:56:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, There is a new mailing list in security area. The discussion will be fruitful if there are people from different backgrounds and not only security (security, operational views, application layer, network layer, privacy, etc). I already invited the people who I could remember. If I missed to invite you, just feel free to join this mailing list. The purpose is to find solutions to automate authentication and use network layer for this means but at the same time take care of performance, privacy and the possibility of this solution. https://www.ietf.org/mailman/listinfo/secauth This is the description of this mailing list. This list is for the discussions relating to using the IP layer as a means of authentication in other upper layers, especially the application layer, by considering both security and privacy on one hand and performance on the other hand. The goal is to come up with the implementation of a library for this purpose. The focus is on both nodes with limited resources (battery, memory, etc) and other nodes. We are also discussing the possible implementation or implementation barriers from operational points of view. Looking forward to see your participations there :-) Thanks, Smile Hosnieh ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello,

 

There = is a new mailing list in security area. The discussion will be fruitful = if there are people from different backgrounds and not only security = (security, operational views, application layer, network layer, privacy, = etc). I already invited the people who I could remember. If I missed to = invite you, just feel free to join this mailing list. The purpose is to = find solutions to automate authentication and use network layer for this = means but at the same time take care of performance, privacy and the = possibility of this solution.

https://www.ietf.org/mail= man/listinfo/secauth

 

This = is the description of this mailing list.

 

This = list is for the discussions relating to using the IP layer as a  = means of authentication in other upper layers, especially the  = application layer, by considering both security and privacy on one  = hand and performance on the other hand. The goal is to come up = with  the implementation of a library for this purpose. The focus = is on  both nodes with limited resources (battery, memory, etc) and = other nodes.

We are also = discussing the possible implementation or implementation  barriers = from operational points of view.

 

Looking forward to see your participations there = :-)

 

 

Thanks,

 

Smile

 

= Hosnieh

 

 

------=_NextPart_000_0042_01CEF691.FB7F0720-- From dwing@cisco.com Wed Dec 11 09:04:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6971AE0A9 for ; Wed, 11 Dec 2013 09:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enNC8_OPmCeq for ; Wed, 11 Dec 2013 09:04:52 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 21C441AE02C for ; Wed, 11 Dec 2013 09:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12506; q=dns/txt; s=iport; t=1386781486; x=1387991086; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zaIMQeJeP+gtw1qzhVVAlJr9MnPl5eqDKegZAHbA+M0=; b=SnM/t3LaK31Ik2Ahgd8o8rDj4mYp/+s2fdLeO1YcPH6Bm0NjnCdt6xWG x2uW2CyItFQZEne967YkDOQmfLKXv2iJfn1b2qQyyLk2LRDKPU4VnScLz Cuv2sPVeF+XSu8h+7PIrXYZJWcNyUcfKA2z05jx8ULl1q02I9wqaTzjMp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFABKaqFKrRDoG/2dsb2JhbABZgwc4TbkfgR0WdIIlAQEBAwEBAQEkPgIHCwULCxUDLiEGMAYTCRKHVQMJBQkFuwkNhmcXjHWBMRACARwzB4MhgRMEiUKKb4F4gWuBMIsqhTmBa4FfG4EuJA X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208";a="96927099" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 11 Dec 2013 17:04:44 +0000 Received: from sjc-vpn5-1459.cisco.com (sjc-vpn5-1459.cisco.com [10.21.93.179]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBBH4gUg003337; Wed, 11 Dec 2013 17:04:42 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Wed, 11 Dec 2013 09:04:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: GangChen X-Mailer: Apple Mail (2.1510) Cc: v6ops Subject: Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:04:54 -0000 On Dec 11, 2013, at 7:04 AM, GangChen wrote: > Thank you for the useful comments. Please see my reply inline. >=20 > 2013/12/11, Dan Wing : >>=20 >> On Dec 8, 2013, at 7:48 PM, GangChen wrote: >>=20 >>> Wg, >>>=20 >>> We have submitted the new version of NAT64 Operational Experience. >>> The updates are summarized as follows: >>>=20 >>> 1) Clarify the case when NAT64 serves as the IPv6 gateway ( Sec. = 3.1.2) >>> 2) Polish the statement of NAT44 & NAT64 co-existing (Sec. 3.1.4) >>> 3) Clarify that the sub-domain configuration is only for the >>> experimental phase (Sec 3.2) >>> 4) Share the data for the scale of sync data in hot standby (Sec = 4.1) >>> 5) Assessing the Impact of NAT64 to applications (Sec. 6.1) >>>=20 >>> Your further reviews/comments are welcome. >>=20 >> draft-ietf-v6ops-nat64-experience-05 reads, in part: >>=20 >> "6.1. Service Reachability >>=20 >> NAT64 is providing a translation capability between IPv6 and IPv4 >> end-nodes. In order to provide the reachability between two IP >> address families, NAT64-CGN has to implement appropriate = application >> aware functions, i.e. Application Layer Gateway (ALG), where = address >> translation is not itself sufficient and security mechanisms do not >> render it infeasible. Most NAT64-CGNs mainly provide FTP- >> ALG[RFC6384]. NAT64-FEs may have functional richness on Load >> Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG = have >> been supported." >>=20 >> Can some text be added describing what an HTTP-ALG, HTTPS-ALG, = RTSP-ALG, and >> SMTP-ALG might do? For HTTP, HTTPS, and maybe RTSP, I guess it adds = a Via >> or X-Forwarded-For so the IPv4 host can get visibility to the = original IPv6 >> address? (I'm not sure.) For SMTP-ALG, I can't guess what it might = do -- >> add a Received: header, or modify the EHLO/HELO exchange? >=20 > Depending on the tests, ALGs detect and change following filed: >=20 > For HTTP, HTTPs, the IP address inserted in the Via filed > For RTSP, the "dest_addr" and "src_addr" in SETUP message > For SMTP, some mail message for trace purpose insert the IP address > in the "Received: " field or "Mail From: " >=20 > To describe what those ALGs might do, the follows texts will be added > for the clarification: >=20 > "NAT64-FEs may have functional richness on Load Balancer, for example > HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have been supported. Those > application protocols exchange IP address and port parameters within > control session, for example the "via" filed in a HTTP header, > "transport" field in a RTSP SETUP message and "Received: " header in > SMTP message. ALG functions will detect those fields and make IP > address translations." >=20 >>=20 >> Later in the table, it reads: >>=20 >> Instance Message|Mostly fail, softwares don't support IPv6 >>=20 >> I think it should be "instant messenger". It seems important to = point out, >> in the document, that the lack of IPv6 support is not the fault or = cause of >> NAT64 technology. Rather, the lack of IPv6 support prevents those >> applications from working on an IPv6-only host or working over IPv6 = on a >> dual-stack host -- that is, they are stuck being IPv4-only = applications. >> The only thing that will help them is 464xlat, which should be = pointed out >> in the document. >=20 > Agree. We will clarify the meaning. >=20 >>=20 >> Then for games it says: >>=20 >> | Games |Mostly pass for web-based games and mostly fail = for | >> | |standalone games due to software supports >>=20 >> Is "due to software supports" the same as "softwares don't support = IPv6", or >> is the different phrasing describing an important difference? >=20 > Same meaning with "softwares don't support IPv6"" >>=20 >> | Email | Pass = | >>=20 >> Is that IMAP, POP, SMTP, or all? Is that with, or without, SMTP-ALG? >=20 > We test POP and SMTP. SMTP-ALG is supported >=20 >>=20 >>=20 >> | VoIP | Fail, due to the lack of SIP-ALG support on = NAT64 | >>=20 >> There certainly are non-SIP VoIP applications -- XMPP for example, = and >> proprietary systems like Skype. If only SIP was tested, say "SIP". >> Furthermore, if the SIP endpoint supports ICE, SIP-ALG is = unnecessary, and >> any successful Internet deployment of a SIP client does need to = support ICE. >> This particular case needs to be tightened up in the document. >=20 > We mainly test SIP-VoIP applications as below stated. I will notice > this information in the table. > The test is made based on 4G mobile environment. The ICE function is > not available at the mobile device side yet at this time. > Your comments are useful, because I didn't realize it should be > recommended to make use of ICE other than implementing ALG on the > NAT64 box. > I will update this row as >=20 > | SIP-VoIP | Fail, due to the lack of SIP NAT64 traversal | ICE is not only useful for NAT traversal, but also firewall traversal = for both IPv4 and IPv6. That is, ICE (or NAT-PMP, or UPnP IGD, or PCP) = is needed if the IPv6 network has simple security (RFC6092). My point, = which I hope can be reflected in your I-D, is that the need for firewall = traversal is not solely because of NAT64, but rather would also be a = requirement for a 100% end-to-end IPv6 network, if that network has a = firewall (and to protect hosts and to protect network bandwidth, a lot = of networks have installed firewalls, they aren't going away!). > Some additional descriptions will be added as below (*) >=20 >=20 >>=20 >> | VPN | Fail, due to incapability of IPsec verification = | >>=20 >> So, this was IPsec VPN, and not "SSL" VPN. That should be clarified = in the >> document. What is "incapability of IPsec verification"? I know the = issue >> you are no doubt referring to, but that could be solved in IPsec >> implementations should they be inclined - but nobody has documented = the >=20 > "incapability of IPsec verification" means the remote peer would = invalidate > the packet since NAT64 changes the header and IPsec-AH likely detect > the change. Yes, it has long been true that IPsec AH does not survive any sort of = network address translation, and IPsec AH also does not survive = translation from IPv6 to IPv4. =20 Nobody much uses IPsec AH because of its incompatibility with NAT. > For IPsec ESP,NAT64 can't update the TCP/UDP checksum, which is = encrypted. > The remote peer is failed to validate the received packages. That isn't at all a problem for IPsec ESP. It works fine through NAT64. = The problem that exists is really in the specified NAT-T behavior for = detecting a NAT, which is done by IKE. >=20 > We will update the row as >=20 > | VPN | Fail for IPsec-based VPN, the translated IPsec > packages are invalidated | >=20 > Would it be helpful if we also add above statement into the draft? "packages" -> "packets". >=20 >=20 >> problem yet. Did you try IPsec-over-UDP or IPsec-over-TCP, and did = those >> also fail? If IPsec native (protocol 50), I guess the CGN-NAT64 had = support >=20 > TCP/UDP is failed due to above reason. >=20 >> for IPsec Passthru which is a defacto standard (but not documented, = and has >> some issues with SPI changing). >=20 > The tested NAT64 can't support this function. So I can't say more on = this point. > Your suggestion would be appreciated. Ah, so your test was IPsec-over-UDP (which failed) and IPsec-over-TCP = (which failed). That's odd; they should both work fine through a NAT64, = assuming the IPv4 IPsec terminator was IPv6-aware (that is, fixed its = NAT-T handling in its IKE code). >=20 >>=20 >> In regard to the widespread applications >> of VoLTE in the near future, SIP-ALG is of great value to be >> implemented on NAT64-CGN. >>=20 >> I whole-heartedly disagree with that sentence. We should be = encouraging >> RFC6157 ("IPv6 Transition in the Session Initiation Protocol (SIP)") = not the >> proliferation of application layer gateways. Application layer = gateways are >> buggy (as is all software) and cause interoperation problems, = interfere with >> deployment of new services, and a myriad of other problems. Their = time has >> come and gone, let's bid ALG farewell and have applications be = responsible >> for their proper function on the network, rather than the network = trying to >> 'help' the applications. >=20 > (*)Really great comments. I incorporate your comments and try to make > following changes: >=20 > =3D=3D=3DOLD=3D=3D=3D >=20 > For VoIP services, we mainly tested Voice over > LTE services[IR.92], which is the major solution for voice in the > fourth generation communication ages. NAT64 is testified with some > issues of SIP-ALG supports. In regard to the widespread = applications > of VoLTE in the near future, SIP-ALG is of great value to be > implemented on NAT64-CGN. >=20 > =3D=3D=3DNew=3D=3D=3D >=20 > For SIP-VoIP services, we mainly tested Voice over > LTE services[IR.92], which is the major solution for voice in the > fourth generation mobile communication age. A nit. I know 3GPP loves calling it Voice over LTE, but isn't it really = RTP over UDP over IP over LTE? Considering the IETF audience for this = eventual RFC, perhaps "Voice over IP over LTE [IR.92]" would be a = reasonable compromise description. > The voice call is failed > due to the lack of NAT64 traveral when an IPv6 SIP user agent = communicates > with an IPv4 SIP user agent. The Interactive Connectivity = Establishment (ICE) > described in [RFC5245]is recommended to be supported as the NAT64 = traveral > mechanism during the SIP IPv6 transition. Add citation to RFC6157 at the end of that sentence, above. > Required functions should be > implemented at SIP client side(e.g. mobile device), and STUN relay = server > and STUN server should be deployment.[RFC6157] describes both = signalling and > media layer process, which should be followed. I would delete the above two sentences; too much detail. -d > BRs >=20 > Gang >=20 >> -d >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> BRs >>>=20 >>> Gang >>>=20 >>> 2013/12/9, internet-drafts@ietf.org : >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the IPv6 Operations Working Group of = the >>>> IETF. >>>>=20 >>>> Title : NAT64 Operational Experience >>>> Author(s) : Gang Chen >>>> Zhen Cao >>>> Chongfeng Xie >>>> David Binet >>>> Filename : draft-ietf-v6ops-nat64-experience-05.txt >>>> Pages : 21 >>>> Date : 2013-12-08 >>>>=20 >>>> Abstract: >>>> This document summarizes NAT64 function deployment scenarios and >>>> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) = and >>>> NAT64 server Front End (NAT64-FE) are considered in this document. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 >>>>=20 >>>> A diff from the previous version is available at: >>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-05 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 From fred@cisco.com Wed Dec 11 09:53:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334D31ADF9C for ; Wed, 11 Dec 2013 09:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.502 X-Spam-Level: X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zODwLtIyIG7g for ; Wed, 11 Dec 2013 09:52:59 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0AA1AD75F for ; Wed, 11 Dec 2013 09:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2747; q=dns/txt; s=iport; t=1386784374; x=1387993974; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5Ug5gGeRAZ3I34J0cmJR1hqEKvW5GKtXd/9Jz7fyEBM=; b=EbEO8k6C83Wte33eV5mH7aGX5TRvfzOzUxMwmqr+UCdeKb0mX7Jahiqb 9hQlOkSu8Xk6s+gahAESQ05+TZgV3l0uzvtLn2LuZQkoAd/07uifNLxjT mQybNBEbX6nK1gCBnE+bzsCKpyiXn5ZYCc5ddydoO7DMikI16zMpJfuZf k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFABilqFKtJXHA/2dsb2JhbABZgwc4TQa5GYEdFnSCJQEBAQMBAQEBZAcbAgEIRicLJQIEEwkFBodoBggFwjEXjw+DIYETBJAxgTGGMoEwkGODKYIq X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="asc'?scan'208";a="6046768" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-3.cisco.com with ESMTP; 11 Dec 2013 17:52:53 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBBHqr5R027061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Dec 2013 17:52:53 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 11:52:53 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt Thread-Index: AQHO9pnQjX0j9cu9DEqJu3cN0V8ikg== Date: Wed, 11 Dec 2013 17:52:52 +0000 Message-ID: <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> In-Reply-To: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.199] Content-Type: multipart/signed; boundary="Apple-Mail=_D06F5B65-8B62-482C-A708-F64259458EA8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:53:01 -0000 --Apple-Mail=_D06F5B65-8B62-482C-A708-F64259458EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks: we have been around this block several times, and I'd like to = bring it to closure. This updates addresses comments raised in a WGLC in = September. My objective is to determine whether there are any remaining = issues, and if not, send it to the IESG. I would like to *not* find = issues in the IETF WGLC coming from this community - I really want to = deal with these here. So... let's take until 20 December to discuss this - WGLC. On Dec 8, 2013, at 7:37 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : NAT64 Operational Experience > Author(s) : Gang Chen > Zhen Cao > Chongfeng Xie > David Binet > Filename : draft-ietf-v6ops-nat64-experience-05.txt > Pages : 21 > Date : 2013-12-08 >=20 > Abstract: > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) = and > NAT64 server Front End (NAT64-FE) are considered in this document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_D06F5B65-8B62-482C-A708-F64259458EA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSqKZfbjEdbHIsm0MRAnc8AKChAAVBQPq6ow//1kJQCsbdupR6PQCgyVLY cI7XB7FuiESt4f637c6Yh2k= =EQ1l -----END PGP SIGNATURE----- --Apple-Mail=_D06F5B65-8B62-482C-A708-F64259458EA8-- From owen@delong.com Wed Dec 11 10:48:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E21ADFDF; Wed, 11 Dec 2013 10:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vK0BaWZ8lX5; Wed, 11 Dec 2013 10:48:23 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A36181ADF9D; Wed, 11 Dec 2013 10:48:22 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBBIkPEY024101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Dec 2013 10:46:26 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBBIkPEY024101 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386787587; bh=3bMoSZza8KdqcwiL098fwvUlltI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LmtD2Z1L/VNf0XFi5wMsdwp2KK+if61Fdgzt/ZiEbuPLmgZg3tGBFgw2/eocrFfrK y8Bot9FW03frilC2EDvEcBNc3YilAyc4ktSPGWg5sWnMdwi/v9wirkX/MwKpElL51p 5YPyAqIeZz83eTh/ciBw/AnUQ6uviguLFE1X2OD0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52A8343C.3040202@gmail.com> Date: Wed, 11 Dec 2013 10:46:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <902F8E77-5A5D-4762-88EB-150118CA1B8F@delong.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 11 Dec 2013 10:46:27 -0800 (PST) Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:48:25 -0000 On Dec 11, 2013, at 1:45 AM, Alexandru Petrescu = wrote: > Le 10/12/2013 18:44, Ole Troan a =E9crit : >>>> In no case do I believe that M or O provide any indication about >>>> IA_PD. >>>=20 >>> You should read RFC 7084 again, then. >>>=20 >>> Standards say what they say, not what you think they should say! >>> :) >>=20 >> RFC7084 isn't a standard. can we please stop this now. having the M/O >> debate one more time is unlikely to provide a different result than >> the previous times we have had this debate. >=20 > I agree we should go past the typical M/O debate, learn from it. >=20 > One way I read the ongoing discussion, if I am not wrong, is that = there > is difficulty created by the lack of a flag specific to IA_PD ("As far > as I know the M flag is linked only to IA_NA. As far as I can see = IA_PD > is not linked to the M flag at all.=94). >=20 > Am I the only to read this as maybe a hint towards necessity of = creation > of a new flag akin to M/O but specific to IA_PD? I.e. it would be = allow > a Router to see whether it may be able to specifically request a > Delegated Prefix even when it would self-configure its address by = other > means than DHCP. I don=92t see the need. A router which wants a prefix should ask for = one. The worst case is it doesn=92t get an answer. The next worst case is it is denied. What is the benefit of having a flag to (sometimes) say that prefixes = are available for the asking? >=20 > (in the past some local thought was given about how RA would advertise = a > capability of delegating prefixes, e.g. this 'D' flag in a draft: >=20 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Code | Checksum | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Cur Hop Limit |M|O|H|Prf|P|D|r| Router Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ) >=20 I wasn=92t around for that discussion, but my guess would be that the = discussion likely came to the same conclusion I did=85 If you want a prefix, ask. A = D flag wouldn=92t really improve anything. Owen From owen@delong.com Wed Dec 11 10:52:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96561ADF79; Wed, 11 Dec 2013 10:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWrMjThqXh-a; Wed, 11 Dec 2013 10:52:40 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 090E21ADF74; Wed, 11 Dec 2013 10:52:39 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBBIpJS5024344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Dec 2013 10:51:20 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBBIpJS5024344 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386787880; bh=yAmQhuJgAJ7o9/8Tx96nkBTGJQg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jxJ9MwuWaulBWdUNv+iYkWdciTrIDoyPVzWvDjnKwHmhUD+l1ob8R1BV9aV/5KYmm kScbmxFqNQT4YAN/L+u+prX+pOp6vIMCChwIiaQGFWv5sjU02sVNnp9oyaqjNSxiv7 0DI60cn4Ye+V/5foBDTG5jRjlHzCKDZSUl/1SC3U= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52A83C92.4020204@gmail.com> Date: Wed, 11 Dec 2013 10:51:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 11 Dec 2013 10:51:20 -0800 (PST) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:52:41 -0000 On Dec 11, 2013, at 2:21 AM, Alexandru Petrescu = wrote: > Le 11/12/2013 11:08, Erik Kline a =E9crit : >>> Am I the only to read this as maybe a hint towards necessity of >>> creation of a new flag akin to M/O but specific to IA_PD? I.e. it >>> would be allow a Router to see whether it may be able to >>> specifically request a Delegated Prefix even when it would >>> self-configure its address by other means than DHCP. >>=20 >> I'm not sure I understand how's that materially different/better >> than a node just trying to request a PD if it wants one, and coping >> with the response (whatever it may be), like it does today. >=20 > Well, as you suggest below, it may save some bytes on the wire, i.e. > would not send the expensive Solicit if the preceding RA said no PD > available. I hardly think that an RS packet could legitimately be called = =93expensive=94. It=92s a relatively small multicast datagram. > I suppose this is the same reason of presence of other flags in the = RA, > like the H (HMIPv6) and P (PMIPv6). As near as I can tell, those flags are for capabilities that are: 1. unlikely to be present on the majority of networks 2. would be much more difficult/expensive to negotiate = without information in the RA. The P flag isn=92t alone in the RA, it=92s also accompanied by a MAP = option in the RA that provides information about the MAP. Owen From scott.brim@gmail.com Wed Dec 11 11:02:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33891ADBCD; Wed, 11 Dec 2013 11:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrvwBGx2pYfh; Wed, 11 Dec 2013 11:02:31 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D517A1AD8D5; Wed, 11 Dec 2013 11:02:30 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so7725320oag.21 for ; Wed, 11 Dec 2013 11:02:25 -0800 (PST) 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 :cc:content-type; bh=795yZDj7DdiP12YnAA7TxcketLfq0rVudJbrto9egtY=; b=lTDwakyGst7PvmVqYGCrcWxsxos8MAniri3M0aco11rnMLOu+KUi1KNBXFOuCEugkL 3OLPFIS9i74cUOBuhLSgqkdQZBCSth6JzP3YoaO8NWIvSMzhwiKnv7gsJ5oFwIzkWTQO 57DizCFCJvXurkFSVQ/5/xjpR/oW5BhiR22MkbCFwUWfcE6plWj6MeccMFVz1sO0oJ+Z UtBGr/CW4BysZJs1QQN7fsnAy1NzhCZB+ssdI/fv9hcL7Ruu2xe81lVVgbP+hhfK4kMV dwD8xvlNrKnGEY3uowFF3g60GpTJA1pwDzuftkHEMjbRH02w8Xp+XQgs2rWxeSgEAH2l km3Q== X-Received: by 10.60.146.229 with SMTP id tf5mr2362568oeb.27.1386788545081; Wed, 11 Dec 2013 11:02:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Wed, 11 Dec 2013 11:02:04 -0800 (PST) In-Reply-To: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> From: Scott Brim Date: Wed, 11 Dec 2013 14:02:04 -0500 Message-ID: To: Hosnieh Rafiee Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , IETF Security Area Advisory Group , "<, apps-discuss@ietf.org>, " , sacm@ietf.org Subject: Re: [v6ops] [apps-discuss] new mailing list in security area X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:02:32 -0000 On Wed, Dec 11, 2013 at 10:56 AM, Hosnieh Rafiee wrote: > The purpose > is to find solutions to automate authentication and use network layer for > this means but at the same time take care of performance, privacy and the > possibility of this solution. > > https://www.ietf.org/mailman/listinfo/secauth Hosnieh, I look forward to this. I start out skeptical, because I suspect that all the reasons for the end-to-end argument will be applicable here, but I remain open-minded. Scott From gert@Space.Net Wed Dec 11 11:34:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74031AE1AE for ; Wed, 11 Dec 2013 11:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of6xGU38PO_D for ; Wed, 11 Dec 2013 11:34:00 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 362311AE15B for ; Wed, 11 Dec 2013 11:33:59 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7479B63AC8 for ; Wed, 11 Dec 2013 20:33:53 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4AB5063AAE for ; Wed, 11 Dec 2013 20:33:53 +0100 (CET) Received: (qmail 74143 invoked by uid 1007); 11 Dec 2013 20:33:53 +0100 Date: Wed, 11 Dec 2013 20:33:53 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20131211193353.GQ81676@Space.Net> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52A8343C.3040202@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) X-Spmfilter-Virus-Scanned: OK Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:34:02 -0000 Hi, On Wed, Dec 11, 2013 at 10:45:32AM +0100, Alexandru Petrescu wrote: > Am I the only to read this as maybe a hint towards necessity of creation > of a new flag akin to M/O but specific to IA_PD? I.e. it would be allow > a Router to see whether it may be able to specifically request a > Delegated Prefix even when it would self-configure its address by other > means than DHCP. Yes. A CPE does IA_PD, always, unless manually configured otherwise. No need for a flag here. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From ietf@rozanak.com Wed Dec 11 12:13:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7611AE0E3; Wed, 11 Dec 2013 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Jo81IobzgX; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9E1ADFA1; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from kopoli (g231191095.adsl.alicedsl.de [92.231.191.95]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmbFL-1VIKM82IcN-00a1zI; Wed, 11 Dec 2013 15:13:42 -0500 From: "Hosnieh Rafiee" To: "'Mouse'" , , , , References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> In-Reply-To: <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> Date: Wed, 11 Dec 2013 21:13:30 +0100 Message-ID: <004201cef6ad$7b2991a0$717cb4e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEbq7nIPHMLdLerYKkR6aMsmA3rUQIznEoGm6RhcbA= Content-Language: en-us X-Provags-ID: V02:K0:oflu91ICOJRXypAx6hSBhPz7vQ4+vbOdldVUBGMY/Et hofng2iypgYTDfKHK0x1C/4hv746RJi9VZ3y73mZ3LMPV7FtGr NZlGxgw/5QelW9ArmkN4gC881vsmN22OJpcJA7e+a73C4ZnEyp EGBHWVovX4KbZ0KVIs2MJewgcqvKVpRiV5MwIDUUfe/41GJSQ0 553grgsCeCQj6yYyaEtdjPxjRFNwos8aFvrDXa1CXo6ME7Eiwc 72lEwpI6JvJHPkiBVoi1Sqagj5p5qfOD2lXpF0grRaUHl/Uq9I 9zSvaelSzxV+jS+YaTZEFyc77G7NNjV52EjL/a4kzSEfEzYyQT wW5oZHaFG5Y/QX8ad1bU= Subject: Re: [v6ops] [saag] new mailing list in security area X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:13:49 -0000 Hi, > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mouse > Sent: Wednesday, December 11, 2013 8:40 PM > To: saag@ietf.org > Subject: Re: [saag] new mailing list in security area > > > There is a new mailing list in security area. [...] > > Sounds possibly up my alley. But... > > > Looking forward to see your participations there :-) > > ...it'd help if you gave the list management address (or at least the list post > address, to which I trust we can just append -request). All I saw was a Web > URL (oddly, present twice, with no explanation of why), and one that was > HTTPS and thus useless to me even if I were willing to use the Web to manage > email (which I'm not). To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/secauth or, via email, send a message with subject or body 'help' to secauth-request@ietf.org You can reach the person managing the list at: secauth-owner@ietf.org Send secaut mailing list submissions to: secauth@ietf.org thanks, smile, Hosnieh From phdgang@gmail.com Wed Dec 11 19:39:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA901AE112 for ; Wed, 11 Dec 2013 19:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd7r33FhaC6k for ; Wed, 11 Dec 2013 19:39:02 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 234561AE10B for ; Wed, 11 Dec 2013 19:39:02 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id i13so1297103qae.9 for ; Wed, 11 Dec 2013 19:38:56 -0800 (PST) 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; bh=dAgJVtxeminsZWbO6VZNH174UMaKyteZW9Ga4BkQAJY=; b=uCeEBSpFisitk55y740Q9WBt9eLKQnSGtChs4qWuSMz0bw1Ht9ok6VYOagvSkJBg5t RmWbgyqbM4W95uIi4lGqIvP0ID61bVhHTv8XpjDHUUAgB/oT7SWS1yRreNIdc0Ogv9k+ ujwCj9R2GH+AJ7qXWHLBvinR8EOnS5xe94WEX5bjYhyZO3iPu+txsKlxHqHkXCAUXGyG ztsJi8lYQbuFXuHNvFoCk8KZqj8WgdR7JHoVdBtoLO9SaFTjMxvgJBEQSdercq2Lor9k 6ntQp4P2seowHK0cUCSlqMQ+j8l5IO/CrcHaw6zKjI+ENnfEjXToy1+e2WF0/Awa39gE z4lA== MIME-Version: 1.0 X-Received: by 10.224.80.129 with SMTP id t1mr1804292qak.95.1386819536176; Wed, 11 Dec 2013 19:38:56 -0800 (PST) Received: by 10.224.172.135 with HTTP; Wed, 11 Dec 2013 19:38:56 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Dec 2013 11:38:56 +0800 Message-ID: From: GangChen To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 03:39:06 -0000 2013/12/12, Dan Wing : > > On Dec 11, 2013, at 7:04 AM, GangChen wrote: > >> Thank you for the useful comments. Please see my reply inline. >> >> 2013/12/11, Dan Wing : >>> >>> On Dec 8, 2013, at 7:48 PM, GangChen wrote: >>> >>>> Wg, >>>> >>>> We have submitted the new version of NAT64 Operational Experience. >>>> The updates are summarized as follows: >>>> >>>> 1) Clarify the case when NAT64 serves as the IPv6 gateway ( Sec. 3.1.2) >>>> 2) Polish the statement of NAT44 & NAT64 co-existing (Sec. 3.1.4) >>>> 3) Clarify that the sub-domain configuration is only for the >>>> experimental phase (Sec 3.2) >>>> 4) Share the data for the scale of sync data in hot standby (Sec 4.1) >>>> 5) Assessing the Impact of NAT64 to applications (Sec. 6.1) >>>> >>>> Your further reviews/comments are welcome. >>> >>> draft-ietf-v6ops-nat64-experience-05 reads, in part: >>> >>> "6.1. Service Reachability >>> >>> NAT64 is providing a translation capability between IPv6 and IPv4 >>> end-nodes. In order to provide the reachability between two IP >>> address families, NAT64-CGN has to implement appropriate application >>> aware functions, i.e. Application Layer Gateway (ALG), where address >>> translation is not itself sufficient and security mechanisms do not >>> render it infeasible. Most NAT64-CGNs mainly provide FTP- >>> ALG[RFC6384]. NAT64-FEs may have functional richness on Load >>> Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have >>> been supported." >>> >>> Can some text be added describing what an HTTP-ALG, HTTPS-ALG, RTSP-ALG, >>> and >>> SMTP-ALG might do? For HTTP, HTTPS, and maybe RTSP, I guess it adds a >>> Via >>> or X-Forwarded-For so the IPv4 host can get visibility to the original >>> IPv6 >>> address? (I'm not sure.) For SMTP-ALG, I can't guess what it might do >>> -- >>> add a Received: header, or modify the EHLO/HELO exchange? >> >> Depending on the tests, ALGs detect and change following filed: >> >> For HTTP, HTTPs, the IP address inserted in the Via filed >> For RTSP, the "dest_addr" and "src_addr" in SETUP message >> For SMTP, some mail message for trace purpose insert the IP address >> in the "Received: " field or "Mail From: " >> >> To describe what those ALGs might do, the follows texts will be added >> for the clarification: >> >> "NAT64-FEs may have functional richness on Load Balancer, for example >> HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have been supported. Those >> application protocols exchange IP address and port parameters within >> control session, for example the "via" filed in a HTTP header, >> "transport" field in a RTSP SETUP message and "Received: " header in >> SMTP message. ALG functions will detect those fields and make IP >> address translations." >> >>> >>> Later in the table, it reads: >>> >>> Instance Message|Mostly fail, softwares don't support IPv6 >>> >>> I think it should be "instant messenger". It seems important to point >>> out, >>> in the document, that the lack of IPv6 support is not the fault or cause >>> of >>> NAT64 technology. Rather, the lack of IPv6 support prevents those >>> applications from working on an IPv6-only host or working over IPv6 on a >>> dual-stack host -- that is, they are stuck being IPv4-only applications. >>> The only thing that will help them is 464xlat, which should be pointed >>> out >>> in the document. >> >> Agree. We will clarify the meaning. >> >>> >>> Then for games it says: >>> >>> | Games |Mostly pass for web-based games and mostly fail for >>> | >>> | |standalone games due to software supports >>> >>> Is "due to software supports" the same as "softwares don't support IPv6", >>> or >>> is the different phrasing describing an important difference? >> >> Same meaning with "softwares don't support IPv6"" >>> >>> | Email | Pass >>> | >>> >>> Is that IMAP, POP, SMTP, or all? Is that with, or without, SMTP-ALG? >> >> We test POP and SMTP. SMTP-ALG is supported >> >>> >>> >>> | VoIP | Fail, due to the lack of SIP-ALG support on NAT64 >>> | >>> >>> There certainly are non-SIP VoIP applications -- XMPP for example, and >>> proprietary systems like Skype. If only SIP was tested, say "SIP". >>> Furthermore, if the SIP endpoint supports ICE, SIP-ALG is unnecessary, >>> and >>> any successful Internet deployment of a SIP client does need to support >>> ICE. >>> This particular case needs to be tightened up in the document. >> >> We mainly test SIP-VoIP applications as below stated. I will notice >> this information in the table. >> The test is made based on 4G mobile environment. The ICE function is >> not available at the mobile device side yet at this time. >> Your comments are useful, because I didn't realize it should be >> recommended to make use of ICE other than implementing ALG on the >> NAT64 box. >> I will update this row as >> >> | SIP-VoIP | Fail, due to the lack of SIP NAT64 traversal | > > ICE is not only useful for NAT traversal, but also firewall traversal for > both IPv4 and IPv6. That is, ICE (or NAT-PMP, or UPnP IGD, or PCP) is > needed if the IPv6 network has simple security (RFC6092). My point, which I > hope can be reflected in your I-D, is that the need for firewall traversal > is not solely because of NAT64, but rather would also be a requirement for a > 100% end-to-end IPv6 network, if that network has a firewall (and to protect > hosts and to protect network bandwidth, a lot of networks have installed > firewalls, they aren't going away!). The text in the row is only specific to the reason for this failure. The use of ICE for firewall traversal may be worth to mentioned in the discussion part, like "The voice call is failed due to the lack of NAT64 traveral when an IPv6 SIP user agent communicates with an IPv4 SIP user agent. The Interactive Connectivity Establishment(ICE) described in [RFC5245]is recommended to be supported as the NAT64 traveral mechanism during the SIP IPv6 transition. [RFC6157] describes both signalling and media layer process, which should be followed. In addition, it may be worth to notice that ICE is not only useful for NAT traversal, but also firewall traversal for both IPv4 and IPv6. Even IPv6 is deployed in an end-to-end manner, ICE still is of great value to avoid the impact of firewall to the SIP procedure." > >> Some additional descriptions will be added as below (*) >> >> >>> >>> | VPN | Fail, due to incapability of IPsec verification >>> | >>> >>> So, this was IPsec VPN, and not "SSL" VPN. That should be clarified in >>> the >>> document. What is "incapability of IPsec verification"? I know the >>> issue >>> you are no doubt referring to, but that could be solved in IPsec >>> implementations should they be inclined - but nobody has documented the >> >> "incapability of IPsec verification" means the remote peer would >> invalidate >> the packet since NAT64 changes the header and IPsec-AH likely detect >> the change. > > Yes, it has long been true that IPsec AH does not survive any sort of > network address translation, and IPsec AH also does not survive translation > from IPv6 to IPv4. > > Nobody much uses IPsec AH because of its incompatibility with NAT. > >> For IPsec ESP,NAT64 can't update the TCP/UDP checksum, which is >> encrypted. >> The remote peer is failed to validate the received packages. > > That isn't at all a problem for IPsec ESP. It works fine through NAT64. > The problem that exists is really in the specified NAT-T behavior for > detecting a NAT, which is done by IKE. > > >> >> We will update the row as >> >> | VPN | Fail for IPsec-based VPN, the translated IPsec >> packages are invalidated | >> >> Would it be helpful if we also add above statement into the draft? > > "packages" -> "packets". > > >> >> >>> problem yet. Did you try IPsec-over-UDP or IPsec-over-TCP, and did >>> those >>> also fail? If IPsec native (protocol 50), I guess the CGN-NAT64 had >>> support >> >> TCP/UDP is failed due to above reason. >> >>> for IPsec Passthru which is a defacto standard (but not documented, and >>> has >>> some issues with SPI changing). >> >> The tested NAT64 can't support this function. So I can't say more on this >> point. >> Your suggestion would be appreciated. > > Ah, so your test was IPsec-over-UDP (which failed) and IPsec-over-TCP (which > failed). That's odd; they should both work fine through a NAT64, assuming > the IPv4 IPsec terminator was IPv6-aware (that is, fixed its NAT-T handling > in its IKE code). It seems NAT-T in IKE is missed on the tested NAT64 box. I guess we should fix this function in the NAT64 box. Anyway, I will document the issues we found so let audiences know NAT64 should be capable of NAT-T IKE. > >> >>> >>> In regard to the widespread applications >>> of VoLTE in the near future, SIP-ALG is of great value to be >>> implemented on NAT64-CGN. >>> >>> I whole-heartedly disagree with that sentence. We should be encouraging >>> RFC6157 ("IPv6 Transition in the Session Initiation Protocol (SIP)") not >>> the >>> proliferation of application layer gateways. Application layer gateways >>> are >>> buggy (as is all software) and cause interoperation problems, interfere >>> with >>> deployment of new services, and a myriad of other problems. Their time >>> has >>> come and gone, let's bid ALG farewell and have applications be >>> responsible >>> for their proper function on the network, rather than the network trying >>> to >>> 'help' the applications. >> >> (*)Really great comments. I incorporate your comments and try to make >> following changes: >> >> ===OLD=== >> >> For VoIP services, we mainly tested Voice over >> LTE services[IR.92], which is the major solution for voice in the >> fourth generation communication ages. NAT64 is testified with some >> issues of SIP-ALG supports. In regard to the widespread applications >> of VoLTE in the near future, SIP-ALG is of great value to be >> implemented on NAT64-CGN. >> >> ===New=== >> >> For SIP-VoIP services, we mainly tested Voice over >> LTE services[IR.92], which is the major solution for voice in the >> fourth generation mobile communication age. > > A nit. I know 3GPP loves calling it Voice over LTE, but isn't it really RTP > over UDP over IP over LTE? Considering the IETF audience for this eventual > RFC, perhaps "Voice over IP over LTE [IR.92]" would be a reasonable > compromise description. The stack for Voice over LTE is RTP over UDP over IP over LTE. Keeping the name in line with GSMA term may be easy to convey this information. BRs Gang > >> The voice call is failed >> due to the lack of NAT64 traveral when an IPv6 SIP user agent >> communicates >> with an IPv4 SIP user agent. The Interactive Connectivity Establishment >> (ICE) >> described in [RFC5245]is recommended to be supported as the NAT64 >> traveral >> mechanism during the SIP IPv6 transition. > > Add citation to RFC6157 at the end of that sentence, above. > >> Required functions should be >> implemented at SIP client side(e.g. mobile device), and STUN relay >> server >> and STUN server should be deployment.[RFC6157] describes both signalling >> and >> media layer process, which should be followed. > > I would delete the above two sentences; too much detail. > > -d > > >> BRs >> >> Gang >> >>> -d >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> BRs >>>> >>>> Gang >>>> >>>> 2013/12/9, internet-drafts@ietf.org : >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the IPv6 Operations Working Group of the >>>>> IETF. >>>>> >>>>> Title : NAT64 Operational Experience >>>>> Author(s) : Gang Chen >>>>> Zhen Cao >>>>> Chongfeng Xie >>>>> David Binet >>>>> Filename : draft-ietf-v6ops-nat64-experience-05.txt >>>>> Pages : 21 >>>>> Date : 2013-12-08 >>>>> >>>>> Abstract: >>>>> This document summarizes NAT64 function deployment scenarios and >>>>> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and >>>>> NAT64 server Front End (NAT64-FE) are considered in this document. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-05 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> > > From Ted.Lemon@nominum.com Wed Dec 11 20:21:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527071ADF7C; Wed, 11 Dec 2013 20:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY7PefZtfYAG; Wed, 11 Dec 2013 20:21:29 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D826C1ADF73; Wed, 11 Dec 2013 20:21:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUqk5w2NESLTXgvl0atleZBTx5v+l19NS@postini.com; Wed, 11 Dec 2013 20:21:23 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1316E1B82D0; Wed, 11 Dec 2013 20:21:23 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0BD3D190043; Wed, 11 Dec 2013 20:21:23 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 20:21:22 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Wed, 11 Dec 2013 23:21:18 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> To: Erik Kline X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 04:21:30 -0000 On Dec 11, 2013, at 5:08 AM, Erik Kline wrote: > I'm not sure I understand how's that materially different/better than > a node just trying to request a PD if it wants one, and coping with > the response (whatever it may be), like it does today. The usual concern is that a bazillion devices all requesting PDs every = so often adds up to a lot of traffic. But since the existing spec = doesn't forbid this, we're stuck with it. From dwing@cisco.com Wed Dec 11 20:31:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF271ADFD7 for ; Wed, 11 Dec 2013 20:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyDEK0EkzOEn for ; Wed, 11 Dec 2013 20:31:00 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF41ADF7C for ; Wed, 11 Dec 2013 20:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15302; q=dns/txt; s=iport; t=1386822654; x=1388032254; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=37u+bLsL1AB38ZQGq7Dp/sZHZK1qnSCNnx1k099z+Eg=; b=d7P4mfNS67lcbK7SM0CHvtJLVv/WjQUt1CFamgycFs0Q0SgkGk0C/qYH M+hmqa+SPWIzS7aWCT8QUB4RfthD7onFw25q58jhT0H9KrHGkQ/MwYIGT 2W+EO9oy0HLIePU+gLln2tOmt9wIIuAuMMrM93/QUBal7uZOG7uhOSkXA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANQ6qVKrRDoG/2dsb2JhbABZgwc4Tbk7gRoWdIIlAQEBAwEBAQEkPgIHCwULCxUDLiEGMAYTCRKHVQMJBQkFuxYNhxIXjHWBMRACARwzB4MhgRMEiUKKb4F4gWuBMIUVhhWFOYFrgV8bgS4k X-IronPort-AV: E=Sophos;i="4.93,876,1378857600"; d="scan'208";a="96981563" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 12 Dec 2013 04:30:53 +0000 Received: from [10.21.78.136] ([10.21.78.136]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBC4Upcn013580; Thu, 12 Dec 2013 04:30:51 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Wed, 11 Dec 2013 20:30:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: GangChen X-Mailer: Apple Mail (2.1510) Cc: v6ops Subject: Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 04:31:03 -0000 On Dec 11, 2013, at 7:38 PM, GangChen wrote: > 2013/12/12, Dan Wing : >>=20 >> On Dec 11, 2013, at 7:04 AM, GangChen wrote: >>=20 >>> Thank you for the useful comments. Please see my reply inline. >>>=20 >>> 2013/12/11, Dan Wing : >>>>=20 >>>> On Dec 8, 2013, at 7:48 PM, GangChen wrote: >>>>=20 >>>>> Wg, >>>>>=20 >>>>> We have submitted the new version of NAT64 Operational Experience. >>>>> The updates are summarized as follows: >>>>>=20 >>>>> 1) Clarify the case when NAT64 serves as the IPv6 gateway ( Sec. = 3.1.2) >>>>> 2) Polish the statement of NAT44 & NAT64 co-existing (Sec. 3.1.4) >>>>> 3) Clarify that the sub-domain configuration is only for the >>>>> experimental phase (Sec 3.2) >>>>> 4) Share the data for the scale of sync data in hot standby (Sec = 4.1) >>>>> 5) Assessing the Impact of NAT64 to applications (Sec. 6.1) >>>>>=20 >>>>> Your further reviews/comments are welcome. >>>>=20 >>>> draft-ietf-v6ops-nat64-experience-05 reads, in part: >>>>=20 >>>> "6.1. Service Reachability >>>>=20 >>>> NAT64 is providing a translation capability between IPv6 and IPv4 >>>> end-nodes. In order to provide the reachability between two IP >>>> address families, NAT64-CGN has to implement appropriate = application >>>> aware functions, i.e. Application Layer Gateway (ALG), where = address >>>> translation is not itself sufficient and security mechanisms do = not >>>> render it infeasible. Most NAT64-CGNs mainly provide FTP- >>>> ALG[RFC6384]. NAT64-FEs may have functional richness on Load >>>> Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG = have >>>> been supported." >>>>=20 >>>> Can some text be added describing what an HTTP-ALG, HTTPS-ALG, = RTSP-ALG, >>>> and >>>> SMTP-ALG might do? For HTTP, HTTPS, and maybe RTSP, I guess it = adds a >>>> Via >>>> or X-Forwarded-For so the IPv4 host can get visibility to the = original >>>> IPv6 >>>> address? (I'm not sure.) For SMTP-ALG, I can't guess what it = might do >>>> -- >>>> add a Received: header, or modify the EHLO/HELO exchange? >>>=20 >>> Depending on the tests, ALGs detect and change following filed: >>>=20 >>> For HTTP, HTTPs, the IP address inserted in the Via filed >>> For RTSP, the "dest_addr" and "src_addr" in SETUP message >>> For SMTP, some mail message for trace purpose insert the IP address >>> in the "Received: " field or "Mail From: " >>>=20 >>> To describe what those ALGs might do, the follows texts will be = added >>> for the clarification: >>>=20 >>> "NAT64-FEs may have functional richness on Load Balancer, for = example >>> HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have been supported. = Those >>> application protocols exchange IP address and port parameters within >>> control session, for example the "via" filed in a HTTP header, >>> "transport" field in a RTSP SETUP message and "Received: " header in >>> SMTP message. ALG functions will detect those fields and make IP >>> address translations." >>>=20 >>>>=20 >>>> Later in the table, it reads: >>>>=20 >>>> Instance Message|Mostly fail, softwares don't support IPv6 >>>>=20 >>>> I think it should be "instant messenger". It seems important to = point >>>> out, >>>> in the document, that the lack of IPv6 support is not the fault or = cause >>>> of >>>> NAT64 technology. Rather, the lack of IPv6 support prevents those >>>> applications from working on an IPv6-only host or working over IPv6 = on a >>>> dual-stack host -- that is, they are stuck being IPv4-only = applications. >>>> The only thing that will help them is 464xlat, which should be = pointed >>>> out >>>> in the document. >>>=20 >>> Agree. We will clarify the meaning. >>>=20 >>>>=20 >>>> Then for games it says: >>>>=20 >>>> | Games |Mostly pass for web-based games and mostly fail = for >>>> | >>>> | |standalone games due to software supports >>>>=20 >>>> Is "due to software supports" the same as "softwares don't support = IPv6", >>>> or >>>> is the different phrasing describing an important difference? >>>=20 >>> Same meaning with "softwares don't support IPv6"" >>>>=20 >>>> | Email | Pass >>>> | >>>>=20 >>>> Is that IMAP, POP, SMTP, or all? Is that with, or without, = SMTP-ALG? >>>=20 >>> We test POP and SMTP. SMTP-ALG is supported >>>=20 >>>>=20 >>>>=20 >>>> | VoIP | Fail, due to the lack of SIP-ALG support on = NAT64 >>>> | >>>>=20 >>>> There certainly are non-SIP VoIP applications -- XMPP for example, = and >>>> proprietary systems like Skype. If only SIP was tested, say "SIP". >>>> Furthermore, if the SIP endpoint supports ICE, SIP-ALG is = unnecessary, >>>> and >>>> any successful Internet deployment of a SIP client does need to = support >>>> ICE. >>>> This particular case needs to be tightened up in the document. >>>=20 >>> We mainly test SIP-VoIP applications as below stated. I will notice >>> this information in the table. >>> The test is made based on 4G mobile environment. The ICE function is >>> not available at the mobile device side yet at this time. >>> Your comments are useful, because I didn't realize it should be >>> recommended to make use of ICE other than implementing ALG on the >>> NAT64 box. >>> I will update this row as >>>=20 >>> | SIP-VoIP | Fail, due to the lack of SIP NAT64 traversal = | >>=20 >> ICE is not only useful for NAT traversal, but also firewall traversal = for >> both IPv4 and IPv6. That is, ICE (or NAT-PMP, or UPnP IGD, or PCP) = is >> needed if the IPv6 network has simple security (RFC6092). My point, = which I >> hope can be reflected in your I-D, is that the need for firewall = traversal >> is not solely because of NAT64, but rather would also be a = requirement for a >> 100% end-to-end IPv6 network, if that network has a firewall (and to = protect >> hosts and to protect network bandwidth, a lot of networks have = installed >> firewalls, they aren't going away!). >=20 > The text in the row is only specific to the reason for this failure. > The use of ICE for firewall traversal may be worth to mentioned in the > discussion part, like >=20 > "The voice call is failed due to the lack of NAT64 traveral when an > IPv6 SIP user agent communicates with an IPv4 SIP user agent. The > Interactive Connectivity Establishment(ICE) > described in [RFC5245]is recommended to be supported as the NAT64 > traveral mechanism during the SIP IPv6 transition. NAT64 is not mentioned in RFC6157, so the above sentence shouldn't = mention NAT64. RFC6157 is just about the transition to v6, for both = dual-stack and single-stack nodes. OLD: ... to be supported as the NAT64 traversal mechanism during the SIP IPv6 = transition. NEW: ... to be supported for SIP IPv6 transition. > [RFC6157] describes both signalling and media layer process, which > should be followed. In addition, it may be worth to notice that ICE is > not only useful for NAT traversal, but also firewall traversal for > both IPv4 and IPv6. Even IPv6 is deployed in an end-to-end manner, ICE > still is of great value to avoid the impact of firewall to the SIP > procedure." >=20 >=20 >>=20 >>> Some additional descriptions will be added as below (*) >>>=20 >>>=20 >>>>=20 >>>> | VPN | Fail, due to incapability of IPsec verification >>>> | >>>>=20 >>>> So, this was IPsec VPN, and not "SSL" VPN. That should be = clarified in >>>> the >>>> document. What is "incapability of IPsec verification"? I know = the >>>> issue >>>> you are no doubt referring to, but that could be solved in IPsec >>>> implementations should they be inclined - but nobody has documented = the >>>=20 >>> "incapability of IPsec verification" means the remote peer would >>> invalidate >>> the packet since NAT64 changes the header and IPsec-AH likely detect >>> the change. >>=20 >> Yes, it has long been true that IPsec AH does not survive any sort of >> network address translation, and IPsec AH also does not survive = translation >> from IPv6 to IPv4. >>=20 >> Nobody much uses IPsec AH because of its incompatibility with NAT. >>=20 >>> For IPsec ESP,NAT64 can't update the TCP/UDP checksum, which is >>> encrypted. >>> The remote peer is failed to validate the received packages. >>=20 >> That isn't at all a problem for IPsec ESP. It works fine through = NAT64. >> The problem that exists is really in the specified NAT-T behavior for >> detecting a NAT, which is done by IKE. >>=20 >>=20 >>>=20 >>> We will update the row as >>>=20 >>> | VPN | Fail for IPsec-based VPN, the translated IPsec >>> packages are invalidated | >>>=20 >>> Would it be helpful if we also add above statement into the draft? >>=20 >> "packages" -> "packets". >>=20 >>=20 >>>=20 >>>=20 >>>> problem yet. Did you try IPsec-over-UDP or IPsec-over-TCP, and did >>>> those >>>> also fail? If IPsec native (protocol 50), I guess the CGN-NAT64 = had >>>> support >>>=20 >>> TCP/UDP is failed due to above reason. >>>=20 >>>> for IPsec Passthru which is a defacto standard (but not documented, = and >>>> has >>>> some issues with SPI changing). >>>=20 >>> The tested NAT64 can't support this function. So I can't say more on = this >>> point. >>> Your suggestion would be appreciated. >>=20 >> Ah, so your test was IPsec-over-UDP (which failed) and IPsec-over-TCP = (which >> failed). That's odd; they should both work fine through a NAT64, = assuming >> the IPv4 IPsec terminator was IPv6-aware (that is, fixed its NAT-T = handling >> in its IKE code). >=20 > It seems NAT-T in IKE is missed on the tested NAT64 box. I guess we > should fix this function in the NAT64 box. =20 Can't be fixed there. > Anyway, I will document > the issues we found so let audiences > know NAT64 should be capable of NAT-T IKE. >=20 >=20 >>=20 >>>=20 >>>>=20 >>>> In regard to the widespread applications >>>> of VoLTE in the near future, SIP-ALG is of great value to be >>>> implemented on NAT64-CGN. >>>>=20 >>>> I whole-heartedly disagree with that sentence. We should be = encouraging >>>> RFC6157 ("IPv6 Transition in the Session Initiation Protocol = (SIP)") not >>>> the >>>> proliferation of application layer gateways. Application layer = gateways >>>> are >>>> buggy (as is all software) and cause interoperation problems, = interfere >>>> with >>>> deployment of new services, and a myriad of other problems. Their = time >>>> has >>>> come and gone, let's bid ALG farewell and have applications be >>>> responsible >>>> for their proper function on the network, rather than the network = trying >>>> to >>>> 'help' the applications. >>>=20 >>> (*)Really great comments. I incorporate your comments and try to = make >>> following changes: >>>=20 >>> =3D=3D=3DOLD=3D=3D=3D >>>=20 >>> For VoIP services, we mainly tested Voice over >>> LTE services[IR.92], which is the major solution for voice in the >>> fourth generation communication ages. NAT64 is testified with some >>> issues of SIP-ALG supports. In regard to the widespread = applications >>> of VoLTE in the near future, SIP-ALG is of great value to be >>> implemented on NAT64-CGN. >>>=20 >>> =3D=3D=3DNew=3D=3D=3D >>>=20 >>> For SIP-VoIP services, we mainly tested Voice over >>> LTE services[IR.92], which is the major solution for voice in the >>> fourth generation mobile communication age. >>=20 >> A nit. I know 3GPP loves calling it Voice over LTE, but isn't it = really RTP >> over UDP over IP over LTE? Considering the IETF audience for this = eventual >> RFC, perhaps "Voice over IP over LTE [IR.92]" would be a reasonable >> compromise description. >=20 > The stack for Voice over LTE is RTP over UDP over IP over LTE. > Keeping the name in line with GSMA term may be easy to convey this = information. It isn't helpful to an IETF audience that may well be unfamiliar with = GSMA/3GPP/ITU terminology, and that VoLTE is really VoIP over some = non-Ethernet layer 2. -d >=20 > BRs >=20 > Gang >>=20 >>> The voice call is failed >>> due to the lack of NAT64 traveral when an IPv6 SIP user agent >>> communicates >>> with an IPv4 SIP user agent. The Interactive Connectivity = Establishment >>> (ICE) >>> described in [RFC5245]is recommended to be supported as the NAT64 >>> traveral >>> mechanism during the SIP IPv6 transition. >>=20 >> Add citation to RFC6157 at the end of that sentence, above. >>=20 >>> Required functions should be >>> implemented at SIP client side(e.g. mobile device), and STUN relay >>> server >>> and STUN server should be deployment.[RFC6157] describes both = signalling >>> and >>> media layer process, which should be followed. >>=20 >> I would delete the above two sentences; too much detail. >>=20 >> -d >>=20 >>=20 >>> BRs >>>=20 >>> Gang >>>=20 >>>> -d >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> BRs >>>>>=20 >>>>> Gang >>>>>=20 >>>>> 2013/12/9, internet-drafts@ietf.org : >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the IPv6 Operations Working Group of = the >>>>>> IETF. >>>>>>=20 >>>>>> Title : NAT64 Operational Experience >>>>>> Author(s) : Gang Chen >>>>>> Zhen Cao >>>>>> Chongfeng Xie >>>>>> David Binet >>>>>> Filename : draft-ietf-v6ops-nat64-experience-05.txt >>>>>> Pages : 21 >>>>>> Date : 2013-12-08 >>>>>>=20 >>>>>> Abstract: >>>>>> This document summarizes NAT64 function deployment scenarios and >>>>>> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) = and >>>>>> NAT64 server Front End (NAT64-FE) are considered in this = document. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-05 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>=20 >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>>=20 >>=20 >>=20 From otroan@employees.org Thu Dec 12 02:02:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460671AE14E; Thu, 12 Dec 2013 02:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgDKouPEk91M; Thu, 12 Dec 2013 02:02:24 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9101ACCDA; Thu, 12 Dec 2013 02:02:22 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKqIqVKQ/khL/2dsb2JhbABZgwe6QoEaFnSCJQEBBAF5EAtGVwaIDwbCRhePCAeDIYETBJAxmXaDKjs X-IronPort-AV: E=Sophos;i="4.93,877,1378857600"; d="asc'?scan'208";a="2060693" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 12 Dec 2013 10:02:14 +0000 Received: from dhcp-10-61-100-80.cisco.com (dhcp-10-61-100-80.cisco.com [10.61.100.80]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBCA2949011748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Dec 2013 10:02:10 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_C90C933E-47E5-4B49-AEE2-75A28B2CE743"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> Date: Thu, 12 Dec 2013 11:02:10 +0100 Message-Id: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1822) Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 10:02:25 -0000 --Apple-Mail=_C90C933E-47E5-4B49-AEE2-75A28B2CE743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> I'm not sure I understand how's that materially different/better than >> a node just trying to request a PD if it wants one, and coping with >> the response (whatever it may be), like it does today. >=20 > The usual concern is that a bazillion devices all requesting PDs every = so often adds up to a lot of traffic. But since the existing spec = doesn't forbid this, we're stuck with it. then you're understanding of "usual" is different from mine. :-) as far as I know this can only happen in very specific circumstances = during transition. we should be more concerned about this idea of using one protocol to = provision another. in this case ND to configure DHCP. is that a good design principle to = follow? cheers, Ole --Apple-Mail=_C90C933E-47E5-4B49-AEE2-75A28B2CE743 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSqYmjAAoJEFuJXizso86g39oIANZT1l3AFMgq8Y38K7EDJ4HO kpNbTd4amMC7z43HCOMP8PGnS8pOklucw+f3v40OuOkW/dBl8ybvuTMECMw1EKoQ Vo9sMFRdyLk8Byf4Vwx4+xS+MgGrAPxI9irn0/2aLM1E49BQOyavDlwPNobQQ6dB 1CpddDTQiDV58k4rG//Onpq/2zfVyOjYuEBShNXZN7iVT0pCAHX0KV0nQ9vDLy9q HkXVr/mQYdds9aMDUQcgM1qkVLFW69Bw6kxhBW+nV/Ysk+H0VGNHzKuEk34G9vq5 99yFniGD2X/gMkLXrvwScBEITM5NS7HfIR+XUGbz0v+/f3QjtoMtUqxVybYg+G4= =ItXq -----END PGP SIGNATURE----- --Apple-Mail=_C90C933E-47E5-4B49-AEE2-75A28B2CE743-- From alexandru.petrescu@gmail.com Thu Dec 12 03:09:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3608E1AD944; Thu, 12 Dec 2013 03:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbr7ikSRXIr8; Thu, 12 Dec 2013 03:09:25 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C0D281AD937; Thu, 12 Dec 2013 03:09:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBCB8snX030686; Thu, 12 Dec 2013 12:08:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3E729205083; Thu, 12 Dec 2013 12:09:13 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2C74D20503E; Thu, 12 Dec 2013 12:09:13 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBCB8ouI026580; Thu, 12 Dec 2013 12:08:53 +0100 Message-ID: <52A99942.5030000@gmail.com> Date: Thu, 12 Dec 2013 12:08:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan , Ted Lemon References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:09:27 -0000 Le 12/12/2013 11:02, Ole Troan a écrit : >>> I'm not sure I understand how's that materially different/better >>> than a node just trying to request a PD if it wants one, and >>> coping with the response (whatever it may be), like it does >>> today. >> >> The usual concern is that a bazillion devices all requesting PDs >> every so often adds up to a lot of traffic. But since the >> existing spec doesn't forbid this, we're stuck with it. > > then you're understanding of "usual" is different from mine. :-) as > far as I know this can only happen in very specific circumstances > during transition. > > we should be more concerned about this idea of using one protocol to > provision another. in this case ND to configure DHCP. is that a good > design principle to follow? PRobably not. Stated as such it would be too limiting (ND to help running _just_ DHCP). Maybe Radius as well. The RA would just say that some means is available to offer a delegated prefix, w/o saying which, without saying whether it is stateful or stateless, secure or insecure, etc. Alex > > cheers, Ole > From otroan@employees.org Thu Dec 12 03:15:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226FF1AE08D; Thu, 12 Dec 2013 03:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhsIZxLr5tZc; Thu, 12 Dec 2013 03:15:38 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25C1AD937; Thu, 12 Dec 2013 03:15:38 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACaaqVKQ/khN/2dsb2JhbABZgwe6QoEcFnSCJgEFeRALRlcGiBXCXhePCAeDIYETBJAxmXaDKjs X-IronPort-AV: E=Sophos;i="4.93,877,1378857600"; d="asc'?scan'208";a="2070484" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 12 Dec 2013 11:15:29 +0000 Received: from dhcp-10-61-100-80.cisco.com (dhcp-10-61-100-80.cisco.com [10.61.100.80]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBCBFPkc013390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Dec 2013 11:15:25 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_F11CA7DD-494B-4BA5-8988-3D10A84DA625"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <52A99942.5030000@gmail.com> Date: Thu, 12 Dec 2013 12:15:24 +0100 Message-Id: <5F250E9B-66B1-4858-9DBC-60CEB50AFE54@employees.org> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> <52A99942.5030000@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:15:40 -0000 --Apple-Mail=_F11CA7DD-494B-4BA5-8988-3D10A84DA625 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alexandru, >>>> I'm not sure I understand how's that materially different/better >>>> than a node just trying to request a PD if it wants one, and >>>> coping with the response (whatever it may be), like it does >>>> today. >>>=20 >>> The usual concern is that a bazillion devices all requesting PDs >>> every so often adds up to a lot of traffic. But since the >>> existing spec doesn't forbid this, we're stuck with it. >>=20 >> then you're understanding of "usual" is different from mine. :-) as >> far as I know this can only happen in very specific circumstances >> during transition. >>=20 >> we should be more concerned about this idea of using one protocol to >> provision another. in this case ND to configure DHCP. is that a good >> design principle to follow? >=20 > PRobably not. Stated as such it would be too limiting (ND to help > running _just_ DHCP). >=20 > Maybe Radius as well. The RA would just say that some means is > available to offer a delegated prefix, w/o saying which, without = saying whether it is stateful or stateless, secure or insecure, etc. for what purpose? would the CE behave any differently if the network advertised that PD = was available or not? cheers, Ole --Apple-Mail=_F11CA7DD-494B-4BA5-8988-3D10A84DA625 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSqZrMAAoJEFuJXizso86gcg4IAMKpTJrRR7qbw1wyEGzluzre XZ4bWsjcVGFtYcav8AOpEi/oym4W3vNGUOsSAD/7jeZGeT2PpPGgv+XQRw4idjpc AMhgB7Dv9BVkLFD2D9A/+/O1DI9eoBCzeozpC/VuArpo20nBvK3Bj204dP3xLqcA LfOkRPeL+Ztqb4h8M8o2wPpInjY+htGSv4RKCOe/tXR8g5TSnrnaYKxKwGJkpbWf uWVfUHP3cBbOe6uVyity60Amj3P1jbTFWNA53aDbsGbWaSZJQ/X+df4zyCWaCjdY o2SHIzwPJrq7yY08flnugSge4fItjc/DYBU4vIsqRmX63O02Hq85TNE20/3wO2E= =tq4+ -----END PGP SIGNATURE----- --Apple-Mail=_F11CA7DD-494B-4BA5-8988-3D10A84DA625-- From alexandru.petrescu@gmail.com Thu Dec 12 04:13:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992E71AC4A7; Thu, 12 Dec 2013 04:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjCeFketDAup; Thu, 12 Dec 2013 04:13:40 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 090F81AC85E; Thu, 12 Dec 2013 04:13:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBCCDRaw018701; Thu, 12 Dec 2013 13:13:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2DC4A201D2C; Thu, 12 Dec 2013 13:13:46 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1B253201172; Thu, 12 Dec 2013 13:13:46 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBCCDQN4031721; Thu, 12 Dec 2013 13:13:26 +0100 Message-ID: <52A9A866.5010901@gmail.com> Date: Thu, 12 Dec 2013 13:13:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <902F8E77-5A5D-4762-88EB-150118CA1B8F@delong.com> In-Reply-To: <902F8E77-5A5D-4762-88EB-150118CA1B8F@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 12:13:42 -0000 Le 11/12/2013 19:46, Owen DeLong a écrit : > > On Dec 11, 2013, at 1:45 AM, Alexandru Petrescu wrote: > >> Le 10/12/2013 18:44, Ole Troan a écrit : >>>>> In no case do I believe that M or O provide any indication about >>>>> IA_PD. >>>> >>>> You should read RFC 7084 again, then. >>>> >>>> Standards say what they say, not what you think they should say! >>>> :) >>> >>> RFC7084 isn't a standard. can we please stop this now. having the M/O >>> debate one more time is unlikely to provide a different result than >>> the previous times we have had this debate. >> >> I agree we should go past the typical M/O debate, learn from it. >> >> One way I read the ongoing discussion, if I am not wrong, is that there >> is difficulty created by the lack of a flag specific to IA_PD ("As far >> as I know the M flag is linked only to IA_NA. As far as I can see IA_PD >> is not linked to the M flag at all.”). > >> >> Am I the only to read this as maybe a hint towards necessity of creation >> of a new flag akin to M/O but specific to IA_PD? I.e. it would be allow >> a Router to see whether it may be able to specifically request a >> Delegated Prefix even when it would self-configure its address by other >> means than DHCP. > > I don’t see the need. A router which wants a prefix should ask for one. > > The worst case is it doesn’t get an answer. > > The next worst case is it is denied. > > What is the benefit of having a flag to (sometimes) say that prefixes are > available for the asking? Just as with addresses, it may be more reliable to configure prefixes by starting with a beacon announcing availability. But yes, it's just another 'what if' case. >> (in the past some local thought was given about how RA would advertise a >> capability of delegating prefixes, e.g. this 'D' flag in a draft: >> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Code | Checksum | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Cur Hop Limit |M|O|H|Prf|P|D|r| Router Lifetime | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ) >> > > I wasn’t around for that discussion, but my guess would be that the discussion > likely came to the same conclusion I did… If you want a prefix, ask. A D flag > wouldn’t really improve anything. It was a local non-IETF discussion. The later versions of that draft eliminated that D flag but I forgot why. It may be as you say. Alex > > Owen > > > From alexandru.petrescu@gmail.com Thu Dec 12 04:17:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C235D1AE257; Thu, 12 Dec 2013 04:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnRs7_Sk1y9h; Thu, 12 Dec 2013 04:17:15 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id BE6931AE256; Thu, 12 Dec 2013 04:17:14 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBCCH3hP031693; Thu, 12 Dec 2013 13:17:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1159C20503E; Thu, 12 Dec 2013 13:17:23 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 016D02012C5; Thu, 12 Dec 2013 13:17:23 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBCCH3K7000927; Thu, 12 Dec 2013 13:17:03 +0100 Message-ID: <52A9A93F.8050804@gmail.com> Date: Thu, 12 Dec 2013 13:17:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 12:17:18 -0000 Le 11/12/2013 19:51, Owen DeLong a écrit : > > On Dec 11, 2013, at 2:21 AM, Alexandru Petrescu > wrote: > >> Le 11/12/2013 11:08, Erik Kline a écrit : >>>> Am I the only to read this as maybe a hint towards necessity >>>> of creation of a new flag akin to M/O but specific to IA_PD? >>>> I.e. it would be allow a Router to see whether it may be able >>>> to specifically request a Delegated Prefix even when it would >>>> self-configure its address by other means than DHCP. >>> >>> I'm not sure I understand how's that materially different/better >>> than a node just trying to request a PD if it wants one, and >>> coping with the response (whatever it may be), like it does >>> today. >> >> Well, as you suggest below, it may save some bytes on the wire, >> i.e. would not send the expensive Solicit if the preceding RA said >> no PD available. > > I hardly think that an RS packet could legitimately be called > “expensive”. Well, I meant DHCP Solicit, not RS. The DHCP exchange would be 4 messages, not two, and spaced by pre-programmed timers and repeats. But yes, on today's fast and fat links with good DHCP implementations, that may be negligible. > It’s a relatively small multicast datagram. > >> I suppose this is the same reason of presence of other flags in the >> RA, like the H (HMIPv6) and P (PMIPv6). > > As near as I can tell, those flags are for capabilities that are: > > 1. unlikely to be present on the majority of networks 2. would be > much more difficult/expensive to negotiate without information in the > RA. > > The P flag isn’t alone in the RA, it’s also accompanied by a MAP > option in the RA that provides information about the MAP. (should the RA provide the delegated prefix as well to compare favorably to the PMIP example? but again this is the 'what if' branch, deviating from the main CPE discussion) Alex > > Owen > > > From alexandru.petrescu@gmail.com Thu Dec 12 04:18:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139701AE264; Thu, 12 Dec 2013 04:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0HWKwmiwUfp; Thu, 12 Dec 2013 04:18:31 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 769881AE262; Thu, 12 Dec 2013 04:18:31 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBCCI7ji023872; Thu, 12 Dec 2013 13:18:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7B1BC2050B3; Thu, 12 Dec 2013 13:18:26 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5F13D205083; Thu, 12 Dec 2013 13:18:26 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBCCI6FO001442; Thu, 12 Dec 2013 13:18:07 +0100 Message-ID: <52A9A97E.5000503@gmail.com> Date: Thu, 12 Dec 2013 13:18:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <20131211193353.GQ81676@Space.Net> In-Reply-To: <20131211193353.GQ81676@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 12:18:33 -0000 Le 11/12/2013 20:33, Gert Doering a écrit : > Hi, > > On Wed, Dec 11, 2013 at 10:45:32AM +0100, Alexandru Petrescu wrote: >> Am I the only to read this as maybe a hint towards necessity of creation >> of a new flag akin to M/O but specific to IA_PD? I.e. it would be allow >> a Router to see whether it may be able to specifically request a >> Delegated Prefix even when it would self-configure its address by other >> means than DHCP. > > Yes. A CPE does IA_PD, always, unless manually configured otherwise. And is there agreement that manual configuration is best? Alex > > No need for a flag here. > > Gert Doering > -- NetMaster > From gert@Space.Net Thu Dec 12 05:27:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0685E1AE2B1 for ; Thu, 12 Dec 2013 05:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzSyqrbb-PHd for ; Thu, 12 Dec 2013 05:27:30 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 719021AD6BF for ; Thu, 12 Dec 2013 05:27:30 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8596563B6F for ; Thu, 12 Dec 2013 14:27:23 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3CAE263B65 for ; Thu, 12 Dec 2013 14:27:23 +0100 (CET) Received: (qmail 18490 invoked by uid 1007); 12 Dec 2013 14:27:23 +0100 Date: Thu, 12 Dec 2013 14:27:23 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20131212132723.GA81676@Space.Net> References: <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <20131211193353.GQ81676@Space.Net> <52A9A97E.5000503@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vPInufQqlcQ9e28b" Content-Disposition: inline In-Reply-To: <52A9A97E.5000503@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) X-Spmfilter-Virus-Scanned: OK Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:27:33 -0000 --vPInufQqlcQ9e28b Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 12, 2013 at 01:18:06PM +0100, Alexandru Petrescu wrote: > Le 11/12/2013 20:33, Gert Doering a =E9crit : > > On Wed, Dec 11, 2013 at 10:45:32AM +0100, Alexandru Petrescu wrote: > >> Am I the only to read this as maybe a hint towards necessity of creati= on > >> of a new flag akin to M/O but specific to IA_PD? I.e. it would be allow > >> a Router to see whether it may be able to specifically request a > >> Delegated Prefix even when it would self-configure its address by other > >> means than DHCP. > > > > Yes. A CPE does IA_PD, always, unless manually configured otherwise. >=20 > And is there agreement that manual configuration is best? For non-default setups, certainly. Default for CPEs needs to be "fully automatic, with prefix delegation", unless it is known for sure that there is no prefix delegation in that particular environment (like: the CPE has no "LAN" links of any sort, by being a node with just a single network interface, or being just a host without routing functionality). Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --vPInufQqlcQ9e28b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUqm5ut9WwGXkzn/FAQIvMw//XW2RZw4GJrjsQgiXdSQr4RLA0KBUZJ9M b0Rrk2FsL3oUlDS0hTlwrlisLpYxG7M2n2zLG711n4/DUTpk2JfOGEGsxvh0XOdw UmJsw1uSWenVwUJlV/JvE+o7p7BRNe57Tnk9G02Zi69LH18gjc4y5KpkaSpXaJUP Y46twN77vyLV4EqIyUZaxhoxodtLPemkKO292Q+rO35m5PTeKJ+TS578Znah7Ai2 qXAE6fHt/4qCsFA7I83p29togZdRcif/rzSVX2oRDntpwY+umNAejLBHdS9/SZ0k w6EjfP1VGPa56B3UkN0R1Jf8GT+Mi6aq0mhkx8FAGhvabXac5maNvnL1KRaqfMzB IE7vOlqVdxOaV3dqU4vJiApmXQRxJXan3yFya6k5t7kqZyjLds0hZd3AKm2FPkFm i4iQgH2b/ha6Wi5yE1DTzH78AEFYM9G4oKjTmyYLCZoAgIS/ato92j1W6YOXYXJ3 c8AUpNpi8q8fSzwolhAbA7q3YYNjEE8D2rcCxis9lzA46r9RWoKFyebGOYBzYXdE eb60IWfdonwSQdc3f+zGTYtU+4adC7rTq61MrXMiZSuzJjSu5CztxxmrJRgz7Vep PhDmyHeZW2rdT0/wHZDKjiUmQljoFbZwtyKfi72T5OEqBascDvK4mYLwHi6GQbVq O+ogUcnGqI4= =Sxhy -----END PGP SIGNATURE----- --vPInufQqlcQ9e28b-- From owen@delong.com Thu Dec 12 11:08:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4012B1AE3EC; Thu, 12 Dec 2013 11:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v56lyzd6E8vI; Thu, 12 Dec 2013 11:08:09 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B81681AE3EB; Thu, 12 Dec 2013 11:08:08 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBCJ5mhn017228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Dec 2013 11:05:59 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBCJ5mhn017228 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386875160; bh=rbpkrYlLfVAaH6uvee3Fp1NPzvs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Vfaxa2ChuuQhLkTZ8rz16baxtlqgApwB01XorMwe+KF+11KUdlYalM0Fso7QStygb wf1AZkinxYvyDcnpUgwwiMVHcNB4Vv3lmB/rS6qJs7yYe8faykwCweupLR9oSXxAjH Xf/OkfgdALoJ6WhsCNrE7Peoga+FV/QBi5RLwD8M= Content-Type: multipart/alternative; boundary="Apple-Mail=_3C354927-D586-4A26-B765-E9D52DCAFD41" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52A9A93F.8050804@gmail.com> Date: Thu, 12 Dec 2013 11:05:47 -0800 Message-Id: <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 12 Dec 2013 11:06:00 -0800 (PST) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 19:08:11 -0000 --Apple-Mail=_3C354927-D586-4A26-B765-E9D52DCAFD41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > (should the RA provide the delegated prefix as well to compare = favorably > to the PMIP example? but again this is the 'what if' branch, deviating > from the main CPE discussion) I don=92t think anyone really wants to move PD into RA. I think that = would be inappropriate, personally. Without moving the PD functionality into RA, then, I would say that the = current situation is fine. CPE should ask for PD if it wants a prefix. It should deal with one of five possible results in response: 1. No response 2. Denial 3. Requested prefix size granted 4. Longer prefix (smaller net block) granted 5. Shorter prefix (larger net block) granted Nobody has yet made a good case for why this behavior is problematic. Owen --Apple-Mail=_3C354927-D586-4A26-B765-E9D52DCAFD41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
(should the RA provide the delegated = prefix as well to compare favorably
to the PMIP example? but again = this is the 'what if' branch, deviating
from the main CPE = discussion)

I don=92t think = anyone really wants to move PD into RA. I think that would be = inappropriate, personally.

Without moving the = PD functionality into RA, then, I would say that the current situation = is fine.

CPE should ask for PD if it wants a = prefix.
It should deal with one of five possible results in = response:

1. No response
2. = Denial
3. Requested prefix size = granted
4. Longer prefix (smaller net block) = granted
5. Shorter prefix (larger net block) = granted

Nobody has yet made a good case for why = this behavior is = problematic.

Owen

= --Apple-Mail=_3C354927-D586-4A26-B765-E9D52DCAFD41-- From gert@Space.Net Thu Dec 12 11:59:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE0D1AE404 for ; Thu, 12 Dec 2013 11:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUUgL7VnvEjl for ; Thu, 12 Dec 2013 11:59:42 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 03B961AE1E8 for ; Thu, 12 Dec 2013 11:59:41 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CCC2463C3A for ; Thu, 12 Dec 2013 20:59:34 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9A4C963C34 for ; Thu, 12 Dec 2013 20:59:34 +0100 (CET) Received: (qmail 85998 invoked by uid 1007); 12 Dec 2013 20:59:34 +0100 Date: Thu, 12 Dec 2013 20:59:34 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20131212195934.GR81676@Space.Net> References: <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) X-Spmfilter-Virus-Scanned: OK Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 19:59:44 -0000 Hi, On Thu, Dec 12, 2013 at 11:05:47AM -0800, Owen DeLong wrote: > Nobody has yet made a good case for why this behavior is problematic. We can't do it that way, because we don't do that in IPv4!! Can't you see? And with DHCP-PD, we can't do NAT! No, this wasn't a serious or useful statement, but half of the discussion wasn't either. Just to reinforce that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From alexandru.petrescu@gmail.com Fri Dec 13 03:22:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D361AE14E; Fri, 13 Dec 2013 03:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkTu1fgQ4vrg; Fri, 13 Dec 2013 03:22:19 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id D762E1AD957; Fri, 13 Dec 2013 03:22:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBDBM8sS029028; Fri, 13 Dec 2013 12:22:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6BE8C20151B; Fri, 13 Dec 2013 12:22:29 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5BAB2201388; Fri, 13 Dec 2013 12:22:29 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBDBM26V028000; Fri, 13 Dec 2013 12:22:08 +0100 Message-ID: <52AAEDDA.6010504@gmail.com> Date: Fri, 13 Dec 2013 12:22:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> In-Reply-To: <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA (was: RFC7084) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 11:22:21 -0000 Le 12/12/2013 20:05, Owen DeLong a écrit : >> (should the RA provide the delegated prefix as well to compare favorably >> to the PMIP example? but again this is the 'what if' branch, deviating >> from the main CPE discussion) > > I don’t think anyone really wants to move PD into RA. I think that would > be inappropriate, personally. > > Without moving the PD functionality into RA, then, I would say that the > current situation is fine. > > CPE should ask for PD if it wants a prefix. > It should deal with one of five possible results in response: > > 1.No response As one senses it, implementing it is not easy. How would one implement the decision 'no response' other than waiting for one a certain amount of time? That wait is what makes people think it takes too long, especially mobile people. Alex > 2.Denial > 3.Requested prefix size granted > 4.Longer prefix (smaller net block) granted > 5.Shorter prefix (larger net block) granted > > Nobody has yet made a good case for why this behavior is problematic. > > Owen > From Ted.Lemon@nominum.com Fri Dec 13 06:56:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056A21AD959; Fri, 13 Dec 2013 06:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3u0H1fAvFQQ; Fri, 13 Dec 2013 06:56:35 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id AECC81A1F3E; Fri, 13 Dec 2013 06:56:35 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUqsgHfyxprQtz5kk/753keEHLBTwPeQJ@postini.com; Fri, 13 Dec 2013 06:56:29 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 52EBF1B82DE; Fri, 13 Dec 2013 06:56:29 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2C809190043; Fri, 13 Dec 2013 06:56:29 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 06:56:29 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Fri, 13 Dec 2013 09:56:23 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <160F8C4E-7523-41FE-8CEA-9528F737D486@nominum.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> To: Ole Troan X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:56:37 -0000 On Dec 12, 2013, at 5:02 AM, Ole Troan wrote: > then you're understanding of "usual" is different from mine. :-) I mean "the concern that is usually raised." > we should be more concerned about this idea of using one protocol to = provision another. > in this case ND to configure DHCP. is that a good design principle to = follow? It's a bit late to be asking that question. From nick@inex.ie Fri Dec 13 07:07:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A531AE309; Fri, 13 Dec 2013 07:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dboGZfZ_g1Cd; Fri, 13 Dec 2013 07:07:00 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id EEC761AE2FC; Fri, 13 Dec 2013 07:06:59 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBDF6j4x038094 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Dec 2013 15:06:46 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host pancake.netability.ie [87.198.142.197] claimed to be crumpet.local Message-ID: <52AB2285.4050602@inex.ie> Date: Fri, 13 Dec 2013 15:06:45 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon , Ole Troan References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> <160F8C4E-7523-41FE-8CEA-9528F737D486@nominum.com> In-Reply-To: <160F8C4E-7523-41FE-8CEA-9528F737D486@nominum.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:07:03 -0000 On 13/12/2013 14:56, Ted Lemon wrote: >> > we should be more concerned about this idea of using one protocol to provision another. >> > in this case ND to configure DHCP. is that a good design principle to follow? > It's a bit late to be asking that question. it's a legitimate question and has been asked by many people for as long as we've had working dhcpv6 implementations. Nick From Ted.Lemon@nominum.com Fri Dec 13 07:17:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D81AE2EB; Fri, 13 Dec 2013 07:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45AMPY3oYLIG; Fri, 13 Dec 2013 07:17:46 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9001AE2E7; Fri, 13 Dec 2013 07:17:46 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUqslFEv6U4l4Qj4UuH95mEySqOXeouOv@postini.com; Fri, 13 Dec 2013 07:17:40 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 26C5F1B82DE; Fri, 13 Dec 2013 07:17:40 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 19161190043; Fri, 13 Dec 2013 07:17:40 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 07:17:40 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <52AB2285.4050602@inex.ie> Date: Fri, 13 Dec 2013 10:17:35 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> <160F8C4E-7523-41FE-8CEA-9528F737D486@nominum.com> <52AB2285.4050602@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:17:48 -0000 On Dec 13, 2013, at 10:06 AM, Nick Hilliard wrote: > it's a legitimate question and has been asked by many people for as = long as > we've had working dhcpv6 implementations. I didn't say it wasn't a legitimate question. I said it's a bit late. = This does not mean we can't propose doing something about it, but bear = in mind that the depths of that rathole have been extensively plumbed by = previous efforts. From owen@delong.com Fri Dec 13 07:52:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106FE1ADFC8; Fri, 13 Dec 2013 07:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-6-bYWrf-fX; Fri, 13 Dec 2013 07:52:52 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 043F51ADBF7; Fri, 13 Dec 2013 07:52:51 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBDFnPeU013261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2013 07:49:26 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBDFnPeU013261 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386949767; bh=O18QQIFNg89bucUSfxqLfwUcjtY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L6Pisi+bW2IQ3GsJsmfT2ECtKnRl9CA7iNjxZPqbTTLHV/pJYqaPcBRIz5AycBHpG jmhkvRpMIyuhiLt+18xRF0/l4R1rdiBQ12HdsAUaYxaFc6XLT6u6ahsDyBbsqdjQLE MeR6Q9foW6wews2S2TgEI8jODBnAqbBhMk5RyCkU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52AAEDDA.6010504@gmail.com> Date: Fri, 13 Dec 2013 07:49:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 13 Dec 2013 07:49:27 -0800 (PST) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA (was: RFC7084) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:52:53 -0000 On Dec 13, 2013, at 3:22 AM, Alexandru Petrescu = wrote: > Le 12/12/2013 20:05, Owen DeLong a =E9crit : >>> (should the RA provide the delegated prefix as well to compare = favorably >>> to the PMIP example? but again this is the 'what if' branch, = deviating >>> from the main CPE discussion) >>=20 >> I don=92t think anyone really wants to move PD into RA. I think that = would >> be inappropriate, personally. >>=20 >> Without moving the PD functionality into RA, then, I would say that = the >> current situation is fine. >>=20 >> CPE should ask for PD if it wants a prefix. >> It should deal with one of five possible results in response: >>=20 >> 1.No response >=20 > As one senses it, implementing it is not easy. >=20 > How would one implement the decision 'no response' other than waiting = for one a certain amount of time? That wait is what makes people think = it takes too long, especially mobile people. Treat it as no response until you get one. Really, what are you going to = do differently after you get denied a prefix (assuming a model of active = denial like you suggest) than you can do while you=92re waiting and = haven=92t yet received a prefix? Either way, you have nothing to delegate to your subordinate networks. >=20 > Alex >=20 >> 2.Denial >> 3.Requested prefix size granted >> 4.Longer prefix (smaller net block) granted >> 5.Shorter prefix (larger net block) granted >>=20 >> Nobody has yet made a good case for why this behavior is problematic. >>=20 >> Owen >>=20 >=20 From otroan@employees.org Fri Dec 13 08:02:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21221AE233; Fri, 13 Dec 2013 08:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmdO7JayNXBe; Fri, 13 Dec 2013 08:02:02 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF8A1AE1F5; Fri, 13 Dec 2013 08:02:01 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMcuq1KQ/khN/2dsb2JhbABZgwq5aoEkFnSCJQEBBAF5EAtGVwaIDwjLHBePFQeDI4ETAQOQM5l3gys7 X-IronPort-AV: E=Sophos;i="4.95,479,1384300800"; d="asc'?scan'208";a="1604992" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 13 Dec 2013 16:01:54 +0000 Received: from dhcp-10-61-105-189.cisco.com (dhcp-10-61-105-189.cisco.com [10.61.105.189]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBDG1os0012288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Dec 2013 16:01:50 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_B086A304-115C-4362-BF19-DCF9AA7A8EDB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <160F8C4E-7523-41FE-8CEA-9528F737D486@nominum.com> Date: Fri, 13 Dec 2013 17:01:41 +0100 Message-Id: <25FF8450-8BA5-467A-A62D-1845B0F2A907@employees.org> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> <160F8C4E-7523-41FE-8CEA-9528F737D486@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1822) Cc: 6man WG , "v6ops@ietf.org" Subject: Re: [v6ops] RFC7084 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:02:03 -0000 --Apple-Mail=_B086A304-115C-4362-BF19-DCF9AA7A8EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, >> then you're understanding of "usual" is different from mine. :-) >=20 > I mean "the concern that is usually raised." >=20 >> we should be more concerned about this idea of using one protocol to = provision another. >> in this case ND to configure DHCP. is that a good design principle to = follow? >=20 > It's a bit late to be asking that question. I think it is most prudent. in that the IETF is in the process of = standardising IPv6 protocol extensions to disable IPv4 (and vice versa), and protocol extensions to IPv6 provisioning to enable IPv4 transport... cheers, Ole --Apple-Mail=_B086A304-115C-4362-BF19-DCF9AA7A8EDB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSqy9mAAoJEFuJXizso86gVywIAL7jfZAYfYJIppchWFs0AMur wQHoGyNl/jlVkynxWyr1cG/R/x+CQSs2HQ6rVy56EGSJSaUohEF4aeMMfN0ub9Ro QdOhi87ASrviBRxgdkaQYrpS7sPkqh6Wd7dYWekHIrGPkxOq343/lM4rqzfoh/sC RyDChGJzMyMc/UyFuVAj3Na9I3BVeh01GwsEiDyXSjtgs92ZspvI8XP+RcggOxWp ZPX5nw+dpUhAZBEEpFFw4cMKuJGXkixEdac21PMTHRzjQBIgIfGuAI+l5zbXYDze k63rugPMjdPk9NS+ucBJ4iuk4xZbo3XaQMkdHby8XZEQo7rqMKqkXeUXonYw9J0= =T7pK -----END PGP SIGNATURE----- --Apple-Mail=_B086A304-115C-4362-BF19-DCF9AA7A8EDB-- From alexandru.petrescu@gmail.com Fri Dec 13 08:11:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC131A1F56; Fri, 13 Dec 2013 08:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVkNLWexGZzn; Fri, 13 Dec 2013 08:11:08 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA521AE320; Fri, 13 Dec 2013 08:11:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBDGAvwu028769; Fri, 13 Dec 2013 17:10:57 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3396205727; Fri, 13 Dec 2013 17:11:17 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D39592056B8; Fri, 13 Dec 2013 17:11:17 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBDGAqhc002772; Fri, 13 Dec 2013 17:10:56 +0100 Message-ID: <52AB318C.2050704@gmail.com> Date: Fri, 13 Dec 2013 17:10:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:11:15 -0000 Le 13/12/2013 16:49, Owen DeLong a écrit : > > On Dec 13, 2013, at 3:22 AM, Alexandru Petrescu > wrote: > >> Le 12/12/2013 20:05, Owen DeLong a écrit : >>>> (should the RA provide the delegated prefix as well to compare >>>> favorably to the PMIP example? but again this is the 'what if' >>>> branch, deviating from the main CPE discussion) >>> >>> I don’t think anyone really wants to move PD into RA. I think >>> that would be inappropriate, personally. >>> >>> Without moving the PD functionality into RA, then, I would say >>> that the current situation is fine. >>> >>> CPE should ask for PD if it wants a prefix. It should deal with >>> one of five possible results in response: >>> >>> 1.No response >> >> As one senses it, implementing it is not easy. >> >> How would one implement the decision 'no response' other than >> waiting for one a certain amount of time? That wait is what makes >> people think it takes too long, especially mobile people. > > Treat it as no response until you get one. There is a problem in the until. Until one gets an answer one can't decide whether or not there is DHCP-PD available. And if one does not have enough time to wait then one would quickly decide there is no DHCP-PD available. On another hand, frequent beacon telling precisely whether or not DHCP-PD is available would lead to more informed decisions. > Really, what are you going to do differently after you get denied a > prefix (assuming a model of active denial like you suggest) than you > can do while you’re waiting and haven’t yet received a prefix? But there is a difference in being denied a particular prefix and DHCP service absence altogether. If the DHCP service is present, there are DHCP means to insist upon being denied a particular prefix (requester another one, etc). If the service is absent there is no reason to insist. > Either way, you have nothing to delegate to your subordinate > networks. Right. If the network tells the node there is no DHCP service to look for, then the node may decide to fall back into a 64share mode, or so. This can happen very quickly (it boils down to evaluating the probability of time length between the random link up signal and the next periodic RA). If on another hand the network does not tell the node whether DHCP is present, then the node must emit a request and wait for a response. If it waits too short and decides there is no service DHCP, even if there is one, then the subsequent decision to use 64share is a wrong decision. That's why conservative DHCP discovery phases take long, and also that's why conservative WiFi AP discovery clients take long, whereas quick such clients often miss some important Access Point. This distinction is even more important for entities which are mainly mobile, doing frequent handovers. (I guess it is also the reason why 802.11p removes altogether all beaconing and discovery activities of 802.11bgn, and proposes a new timestamp beacon - too long for essentially moving devices.) Alex > >> >> Alex >> >>> 2.Denial 3.Requested prefix size granted 4.Longer prefix >>> (smaller net block) granted 5.Shorter prefix (larger net block) >>> granted >>> >>> Nobody has yet made a good case for why this behavior is >>> problematic. >>> >>> Owen >>> >> > > > From owen@delong.com Fri Dec 13 08:48:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365071ADFCB; Fri, 13 Dec 2013 08:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K576kw-wUm1M; Fri, 13 Dec 2013 08:48:15 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C2AE71ADFC6; Fri, 13 Dec 2013 08:48:14 -0800 (PST) Received: from [10.219.5.18] (mobile-198-228-209-223.mycingular.net [198.228.209.223]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBDGiFej016054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2013 08:44:16 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBDGiFej016054 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386953057; bh=b9V94XcP6Mb9zHfma3cWOBW+FDU=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=hAxXTlBkeBB67+9/9kwkSmyjHfdu2DOkfZx7iavr5PPnNRur5bDBB3o6Ltva446zi h1AIJK9qW7Lk3Z4NtEwtJu0BpG8Q44GpRYMOS3opQ/U2T/Sm5MlouymH0+WHlkI89E mHhLRLdJBRrao9lLTqSPLyQ3bvx8rf8GKNIYMmjk= References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52AB318C.2050704@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: Owen DeLong Date: Fri, 13 Dec 2013 08:39:14 -0800 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 13 Dec 2013 08:44:17 -0800 (PST) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:48:17 -0000 >> Treat it as no response until you get one. >=20 > There is a problem in the until. >=20 Is there? What? What would you do differently with a deterministic no? > Until one gets an answer one can't decide whether or not there is > DHCP-PD available. And if one does not have enough time to wait then > one would quickly decide there is no DHCP-PD available. Does it matter? What matters is that you don't have a prefix to delegate. Again, I ask... What do you do differently with a deterministic no vs. a lac= k of information? > On another hand, frequent beacon telling precisely whether or not > DHCP-PD is available would lead to more informed decisions. It would also lead to a number of other problems in many networks. >> Really, what are you going to do differently after you get denied a >> prefix (assuming a model of active denial like you suggest) than you >> can do while you=E2=80=99re waiting and haven=E2=80=99t yet received a pr= efix? >=20 > But there is a difference in being denied a particular prefix and DHCP > service absence altogether. If you have DHCP service present, then, you should get a denial response to I= A_PD relatively quickly if you ask. The timeout should only apply to circums= tances where there is no DHCP. > If the DHCP service is present, there are DHCP means to insist upon > being denied a particular prefix (requester another one, etc). If the DHCP service is present, you should see an M or O bit in the RA. Howe= ver, that shouldn't control whether you indicate your desire for a prefix or= not. > If the service is absent there is no reason to insist. I'm not sure what you mean by insist in this context. I would agree that the= re is no reason to persist with alternative requests in the absence of a den= ial. That you should, instead, retry the same request until receiving an ack= nowledgement or a denial. >> Either way, you have nothing to delegate to your subordinate >> networks. >=20 > Right. >=20 > If the network tells the node there is no DHCP service to look for, then > the node may decide to fall back into a 64share mode, or so. This can > happen very quickly (it boils down to evaluating the probability of time > length between the random link up signal and the next periodic RA). Is there any reason not to use 64share mode until you receive a positive DHC= P response? > If on another hand the network does not tell the node whether DHCP is > present, then the node must emit a request and wait for a response. If > it waits too short and decides there is no service DHCP, even if there > is one, then the subsequent decision to use 64share is a wrong decision. No, it must emit a request. It does not have to wait for the response, the r= esponse can be processed asynchronously. I don't see the decision to use 64s= hare is wrong so much as suboptimal. It's not at all invalid to use 64share u= ntil receiving the PD and then switch to the delegated prefix. If you want t= o provide a better user experience, 64share behavior can be preserved for so= me duration until early flows expire. Simply stop including 64share prefix i= n locally generated RAs and wait for valid timer to count down. > That's why conservative DHCP discovery phases take long, and also that's > why conservative WiFi AP discovery clients take long, whereas quick such > clients often miss some important Access Point. Discovering an AP has nothing to do with DHCP and has to happen well before t= he first piece of the DHCP process. > This distinction is even more important for entities which are mainly > mobile, doing frequent handovers. If you're doing frequent handovers and they are changing your layer 3 topolo= gy frequently then you already have a number of other problems which go well= beyond the difficulties you are describing here. Most frequent handovers in the mobile world do not affect the layer 3 inform= ation. > (I guess it is also the reason why 802.11p removes altogether all > beaconing and discovery activities of 802.11bgn, and proposes a new > timestamp beacon - too long for essentially moving devices.) Among other reasons. Owen >=20 > Alex >=20 >>=20 >>>=20 >>> Alex >>>=20 >>>> 2.Denial 3.Requested prefix size granted 4.Longer prefix >>>> (smaller net block) granted 5.Shorter prefix (larger net block) >>>> granted >>>>=20 >>>> Nobody has yet made a good case for why this behavior is >>>> problematic. >>>>=20 >>>> Owen >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 From alexandru.petrescu@gmail.com Fri Dec 13 09:43:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4151ADF7E; Fri, 13 Dec 2013 09:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hvFmyHMYP_y; Fri, 13 Dec 2013 09:43:03 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C73E51ADED6; Fri, 13 Dec 2013 09:43:02 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBDHgn0h010061; Fri, 13 Dec 2013 18:42:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E7EB72057B0; Fri, 13 Dec 2013 18:43:10 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DED6F205759; Fri, 13 Dec 2013 18:43:10 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBDHgk3w007552; Fri, 13 Dec 2013 18:42:49 +0100 Message-ID: <52AB4716.4040902@gmail.com> Date: Fri, 13 Dec 2013 18:42:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:43:05 -0000 Le 13/12/2013 17:39, Owen DeLong a écrit : >>> Treat it as no response until you get one. >> >> There is a problem in the until. >> > > Is there? What? What would you do differently with a deterministic > no? > >> Until one gets an answer one can't decide whether or not there is >> DHCP-PD available. And if one does not have enough time to wait >> then one would quickly decide there is no DHCP-PD available. > > Does it matter? What matters is that you don't have a prefix to > delegate. > > Again, I ask... What do you do differently with a deterministic no > vs. a lack of information? > >> On another hand, frequent beacon telling precisely whether or not >> DHCP-PD is available would lead to more informed decisions. > > It would also lead to a number of other problems in many networks. > >>> Really, what are you going to do differently after you get >>> denied a prefix (assuming a model of active denial like you >>> suggest) than you can do while you’re waiting and haven’t yet >>> received a prefix? >> >> But there is a difference in being denied a particular prefix and >> DHCP service absence altogether. > > If you have DHCP service present, then, you should get a denial > response to IA_PD relatively quickly if you ask. The timeout should > only apply to circumstances where there is no DHCP. > >> If the DHCP service is present, there are DHCP means to insist upon >> being denied a particular prefix (requester another one, etc). > > If the DHCP service is present, you should see an M or O bit in the > RA. However, that shouldn't control whether you indicate your desire > for a prefix or not. Well, I think I disagree. Since the widespread SLAAC has no PD feature it's easy to consider that a node would SLAAC its address and DHCP-PD its prefix for behind. Or DHCP its address and prefix. But the M/O bits can't indicate to SLAAC address and DHCP-PD prefix. >> If the service is absent there is no reason to insist. > > I'm not sure what you mean by insist in this context. I would agree > that there is no reason to persist with alternative requests in the > absence of a denial. That you should, instead, retry the same > request until receiving an acknowledgement or a denial. > >>> Either way, you have nothing to delegate to your subordinate >>> networks. >> >> Right. >> >> If the network tells the node there is no DHCP service to look >> for, then the node may decide to fall back into a 64share mode, or >> so. This can happen very quickly (it boils down to evaluating the >> probability of time length between the random link up signal and >> the next periodic RA). > > Is there any reason not to use 64share mode until you receive a > positive DHCP response? Sure. There are reasons to not use 64share altogether. It does not work on 4G links like CDC-Ethernet. It has other drawbacks described in a draft. Instlaling 64share followed by a positive DHCP-PD Ack involves renumbering the Host in smartphone's network, i.e. breaking their ongoing communications (the prefix of 64share is different than the prefix obtained by DHCP PD). >> If on another hand the network does not tell the node whether DHCP >> is present, then the node must emit a request and wait for a >> response. If it waits too short and decides there is no service >> DHCP, even if there is one, then the subsequent decision to use >> 64share is a wrong decision. > > No, it must emit a request. It does not have to wait for the > response, the response can be processed asynchronously. I don't see > the decision to use 64share is wrong so much as suboptimal. It's not > at all invalid to use 64share until receiving the PD and then switch > to the delegated prefix. The smartphone may switch, but renumbering all the Hosts in smartphone's hotspot? > If you want to provide a better user experience, 64share behavior can > be preserved for some duration until early flows expire. Simply stop > including 64share prefix in locally generated RAs and wait for valid > timer to count down. I agree. Althoug measuring how flows may expire may not be straightforward. >> That's why conservative DHCP discovery phases take long, and also >> that's why conservative WiFi AP discovery clients take long, >> whereas quick such clients often miss some important Access Point. > > Discovering an AP has nothing to do with DHCP and has to happen well > before the first piece of the DHCP process. Hmmm... they have nothing to do (different layers). Yes, link association must happen before DHCP process. Link association involves a discovery phase. Worse, the 3 can't be parallelized. Their discovery algorithms work in the same way: their messages and core data structures have similar semantics: ND's RS and DHCP's Request is WiFi's Ass'n Request, ND's RA and DHCP's Reply is WiFi's Beacon, ND cache and DHCP's cache is WiFi's preferred networks, etc. >> This distinction is even more important for entities which are >> mainly mobile, doing frequent handovers. > > If you're doing frequent handovers and they are changing your layer > 3 topology frequently then you already have a number of other > problems which go well beyond the difficulties you are describing > here. YEs, just to say they exacerbate this perspective. > Most frequent handovers in the mobile world do not affect the layer > 3 information. YEs, I agree. I guess by most mobile world is meant smartphones on cellular links. YEs, they are widely deployed and involve expensive business cases. The good thing is thatthere's more to it than that: smartphones handing over between wifi and cellular links, smartphones handing over from one operator to another, bus train and roadside IP deployments, DMM concepts, etc. Alex > >> (I guess it is also the reason why 802.11p removes altogether all >> beaconing and discovery activities of 802.11bgn, and proposes a new >> timestamp beacon - too long for essentially moving devices.) > > Among other reasons. > > Owen > >> >> Alex >> >>> >>>> >>>> Alex >>>> >>>>> 2.Denial 3.Requested prefix size granted 4.Longer prefix >>>>> (smaller net block) granted 5.Shorter prefix (larger net >>>>> block) granted >>>>> >>>>> Nobody has yet made a good case for why this behavior is >>>>> problematic. >>>>> >>>>> Owen >>>>> >>>> >>> >>> >>> >> > > From owen@delong.com Fri Dec 13 10:22:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677891ADF77; Fri, 13 Dec 2013 10:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.992 X-Spam-Level: X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eji-M55OUuRb; Fri, 13 Dec 2013 10:22:38 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 667D81AD8F0; Fri, 13 Dec 2013 10:22:37 -0800 (PST) Received: from [10.219.5.18] (mobile-198-228-209-223.mycingular.net [198.228.209.223]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBDIHQ4N019644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2013 10:17:27 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBDIHQ4N019644 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386958649; bh=KTxGAijLbg6SUNNA8Sh1VeNvr08=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=5sn7GCMMUJRA0NVWk2J165WAS0iPlMCDOVY4zGlPpmDnw3c+2Fsa/xcmeEdsSXL5e iqJ4W16dX8eZS+s54xqeOLvuMkdUS6UjRsiiLqSJJoHRhrvjrj5NYvcd1VGjE67dSv fhTGfBtfzXwJHF1CT0VfgVbe2V98R3All00CpJVo= References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> <52AB4716.4040902@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52AB4716.4040902@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: Owen DeLong Date: Fri, 13 Dec 2013 10:17:26 -0800 To: Alexandru Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 13 Dec 2013 10:17:29 -0800 (PST) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:22:40 -0000 >> If the DHCP service is present, you should see an M or O bit in the >> RA. However, that shouldn't control whether you indicate your desire >> for a prefix or not. >=20 > Well, I think I disagree Well... > Since the widespread SLAAC has no PD feature it's easy to consider that > a node would SLAAC its address and DHCP-PD its prefix for behind. Or > DHCP its address and prefix. I suppose it is possible that someone would run a DHCP server strictly for P= D and not offer up other configuration options to hosts (remember, O bit mea= ns ask DHCP for "other information"), so without the M bit, you shouldn't be= expecting DHCP to provide an address. > But the M/O bits can't indicate to SLAAC address and DHCP-PD prefix. The O bit doesn't specifically indicate to ask for prefix, true. However, it= does indicate that there is a DHCP server available and that other informat= ion should be requested from said DHCP server. I would think that the rational thing to do in an environment where you want= to provide DHCP-PD and not other information via DHCP (which is hard for me= to imagine why, but let's ignore that for the moment) would be to advertise= an O bit and then answer with empty or negative responses for non PD reques= ts. >>> If the service is absent there is no reason to insist. >>=20 >> I'm not sure what you mean by insist in this context. I would agree >> that there is no reason to persist with alternative requests in the >> absence of a denial. That you should, instead, retry the same >> request until receiving an acknowledgement or a denial. >>=20 >>>> Either way, you have nothing to delegate to your subordinate >>>> networks. >>>=20 >>> Right. >>>=20 >>> If the network tells the node there is no DHCP service to look >>> for, then the node may decide to fall back into a 64share mode, or >>> so. This can happen very quickly (it boils down to evaluating the >>> probability of time length between the random link up signal and >>> the next periodic RA). >>=20 >> Is there any reason not to use 64share mode until you receive a >> positive DHCP response? >=20 > Sure. There are reasons to not use 64share altogether. It does not > work on 4G links like CDC-Ethernet. It has other drawbacks described in > a draft. But it's not going to be any worse than what happens while you don't have a p= refix. > Instlaling 64share followed by a positive DHCP-PD Ack involves > renumbering the Host in smartphone's network, i.e. breaking their > ongoing communications (the prefix of 64share is different than the > prefix obtained by DHCP PD). I believe I discussed ways to mitigate this above. >>> If on another hand the network does not tell the node whether DHCP >>> is present, then the node must emit a request and wait for a >>> response. If it waits too short and decides there is no service >>> DHCP, even if there is one, then the subsequent decision to use >>> 64share is a wrong decision. >>=20 >> No, it must emit a request. It does not have to wait for the >> response, the response can be processed asynchronously. I don't see >> the decision to use 64share is wrong so much as suboptimal. It's not >> at all invalid to use 64share until receiving the PD and then switch >> to the delegated prefix. >=20 > The smartphone may switch, but renumbering all the Hosts in smartphone's > hotspot? Why not? They're no worse off than they would have been if they'd been stuck= waiting for a DHCP response. >> If you want to provide a better user experience, 64share behavior can >> be preserved for some duration until early flows expire. Simply stop >> including 64share prefix in locally generated RAs and wait for valid >> timer to count down. >=20 > I agree. Althoug measuring how flows may expire may not be straightforwar= d. If you can't be sure the flows expired (easy with TCP, harder with other pro= tocols), then you use the Valid timer and you're done. >>> That's why conservative DHCP discovery phases take long, and also >>> that's why conservative WiFi AP discovery clients take long, >>> whereas quick such clients often miss some important Access Point. >>=20 >> Discovering an AP has nothing to do with DHCP and has to happen well >> before the first piece of the DHCP process. >=20 > Hmmm... they have nothing to do (different layers). Yes, link > association must happen before DHCP process. Link association involves > a discovery phase. Worse, the 3 can't be parallelized. >=20 > Their discovery algorithms work in the same way: their messages and core > data structures have similar semantics: ND's RS and DHCP's Request is > WiFi's Ass'n Request, ND's RA and DHCP's Reply is WiFi's Beacon, ND > cache and DHCP's cache is WiFi's preferred networks, etc. Perhaps that is because many years of research and experience has shown that= these mechanisms work. >>> This distinction is even more important for entities which are >>> mainly mobile, doing frequent handovers. >>=20 >> If you're doing frequent handovers and they are changing your layer >> 3 topology frequently then you already have a number of other >> problems which go well beyond the difficulties you are describing >> here. >=20 > YEs, just to say they exacerbate this perspective. >=20 >> Most frequent handovers in the mobile world do not affect the layer >> 3 information. >=20 > YEs, I agree. >=20 > I guess by most mobile world is meant smartphones on cellular links. > YEs, they are widely deployed and involve expensive business cases. >=20 > The good thing is thatthere's more to it than that: smartphones handing > over between wifi and cellular links, smartphones handing over from one > operator to another, bus train and roadside IP deployments, DMM > concepts, etc. Mobile is a tough problem to solve, to be sure. There's lots of work and opt= imization to be done in this area in the future. I'm still not convinced tha= t adding a "PD available" flag to RA provides a benefit. Owen From alexandru.petrescu@gmail.com Fri Dec 13 13:28:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356771AE052; Fri, 13 Dec 2013 13:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.417 X-Spam-Level: * X-Spam-Status: No, score=1.417 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbKKOfDb084V; Fri, 13 Dec 2013 13:27:57 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by ietfa.amsl.com (Postfix) with ESMTP id CCF391ADF68; Fri, 13 Dec 2013 13:27:55 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 25DC0D48002; Fri, 13 Dec 2013 22:27:20 +0100 (CET) Message-ID: <52AB7BB6.2080002@gmail.com> Date: Fri, 13 Dec 2013 22:27:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> <52AB4716.4040902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 131213-0, 13/12/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 21:28:00 -0000 On 13/12/2013 19:17, Owen DeLong wrote: >>> If the DHCP service is present, you should see an M or O bit in >>> the RA. However, that shouldn't control whether you indicate >>> your desire for a prefix or not. >> >> Well, I think I disagree > > Well... > >> Since the widespread SLAAC has no PD feature it's easy to consider >> that a node would SLAAC its address and DHCP-PD its prefix for >> behind. Or DHCP its address and prefix. > > I suppose it is possible that someone would run a DHCP server > strictly for PD and not offer up other configuration options to > hosts (remember, O bit means ask DHCP for "other information"), so > without the M bit, you shouldn't be expecting DHCP to provide an > address. > >> But the M/O bits can't indicate to SLAAC address and DHCP-PD >> prefix. > > The O bit doesn't specifically indicate to ask for prefix, true. > However, it does indicate that there is a DHCP server available and > that other information should be requested from said DHCP server. Right, I missed this part. > I would think that the rational thing to do in an environment where > you want to provide DHCP-PD and not other information via DHCP > (which is hard for me to imagine why, but let's ignore that for the > moment) would be to advertise an O bit and then answer with empty or > negative responses for non PD requests. Right - reset M, set O and answer negatively to non-PD DHCP requests. But how about when the Delegated Prefix is available, but via 'other other' means than DHCP such as Radius, or via PPP? There is no bit for that either. The 'O' and 'M' bits apply only to DHCP. It would be clearer if there were 1 bit for each of the fundamental addressing aspects (address, default route, delegated prefix, etc.) and each would be 'O' - Address available by other means than this RA, Default route available by other means than this RA, Delegated prefix available by other means than this RA, etc. Alex >>>> If the service is absent there is no reason to insist. >>> >>> I'm not sure what you mean by insist in this context. I would >>> agree that there is no reason to persist with alternative >>> requests in the absence of a denial. That you should, instead, >>> retry the same request until receiving an acknowledgement or a >>> denial. >>> >>>>> Either way, you have nothing to delegate to your subordinate >>>>> networks. >>>> >>>> Right. >>>> >>>> If the network tells the node there is no DHCP service to look >>>> for, then the node may decide to fall back into a 64share >>>> mode, or so. This can happen very quickly (it boils down to >>>> evaluating the probability of time length between the random >>>> link up signal and the next periodic RA). >>> >>> Is there any reason not to use 64share mode until you receive a >>> positive DHCP response? >> >> Sure. There are reasons to not use 64share altogether. It does >> not work on 4G links like CDC-Ethernet. It has other drawbacks >> described in a draft. > > But it's not going to be any worse than what happens while you don't > have a prefix. Right. >> Instlaling 64share followed by a positive DHCP-PD Ack involves >> renumbering the Host in smartphone's network, i.e. breaking their >> ongoing communications (the prefix of 64share is different than the >> prefix obtained by DHCP PD). > > I believe I discussed ways to mitigate this above. > >>>> If on another hand the network does not tell the node whether >>>> DHCP is present, then the node must emit a request and wait >>>> for a response. If it waits too short and decides there is no >>>> service DHCP, even if there is one, then the subsequent >>>> decision to use 64share is a wrong decision. >>> >>> No, it must emit a request. It does not have to wait for the >>> response, the response can be processed asynchronously. I don't >>> see the decision to use 64share is wrong so much as suboptimal. >>> It's not at all invalid to use 64share until receiving the PD >>> and then switch to the delegated prefix. >> >> The smartphone may switch, but renumbering all the Hosts in >> smartphone's hotspot? > > Why not? They're no worse off than they would have been if they'd > been stuck waiting for a DHCP response. > >>> If you want to provide a better user experience, 64share >>> behavior can be preserved for some duration until early flows >>> expire. Simply stop including 64share prefix in locally generated >>> RAs and wait for valid timer to count down. >> >> I agree. Althoug measuring how flows may expire may not be >> straightforward. > > If you can't be sure the flows expired (easy with TCP, harder with > other protocols), then you use the Valid timer and you're done. I haven't seen this done elsewhere... Alex >>>> That's why conservative DHCP discovery phases take long, and >>>> also that's why conservative WiFi AP discovery clients take >>>> long, whereas quick such clients often miss some important >>>> Access Point. >>> >>> Discovering an AP has nothing to do with DHCP and has to happen >>> well before the first piece of the DHCP process. >> >> Hmmm... they have nothing to do (different layers). Yes, link >> association must happen before DHCP process. Link association >> involves a discovery phase. Worse, the 3 can't be parallelized. >> >> Their discovery algorithms work in the same way: their messages >> and core data structures have similar semantics: ND's RS and >> DHCP's Request is WiFi's Ass'n Request, ND's RA and DHCP's Reply is >> WiFi's Beacon, ND cache and DHCP's cache is WiFi's preferred >> networks, etc. > > Perhaps that is because many years of research and experience has > shown that these mechanisms work. > >>>> This distinction is even more important for entities which are >>>> mainly mobile, doing frequent handovers. >>> >>> If you're doing frequent handovers and they are changing your >>> layer 3 topology frequently then you already have a number of >>> other problems which go well beyond the difficulties you are >>> describing here. >> >> YEs, just to say they exacerbate this perspective. >> >>> Most frequent handovers in the mobile world do not affect the >>> layer 3 information. >> >> YEs, I agree. >> >> I guess by most mobile world is meant smartphones on cellular >> links. YEs, they are widely deployed and involve expensive >> business cases. >> >> The good thing is thatthere's more to it than that: smartphones >> handing over between wifi and cellular links, smartphones handing >> over from one operator to another, bus train and roadside IP >> deployments, DMM concepts, etc. > > Mobile is a tough problem to solve, to be sure. There's lots of work > and optimization to be done in this area in the future. I'm still > not convinced that adding a "PD available" flag to RA provides a > benefit. > > Owen > > --- Ce courrier =E9lectronique ne contient aucun virus ou logiciel malveillant = parce que la protection avast! Antivirus est active. http://www.avast.com From owen@delong.com Fri Dec 13 14:03:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1D21ADFC7; Fri, 13 Dec 2013 14:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVmckKHpSWv0; Fri, 13 Dec 2013 14:03:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AA4501AE41A; Fri, 13 Dec 2013 14:03:08 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBDM1Sfp024656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2013 14:01:39 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBDM1Sfp024656 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386972099; bh=Yq59ZHBxccaD/gRBaa4O1tAtoBI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=wUaTidl6X2RCFEk22aFIQAuq7hECHUnIr/0XpFY+YxhvhI35hX3sGhUss5mRqmFMf zWdujF1BT/fakugGBomhrYUejQr0KEXR2ZXYd04Lj3EcQoyZpR5jv25EXa1MmTOwZz O6tbejrk0Opf1E8UPTImM/b1lo676qL6PzTB0S60= Content-Type: multipart/alternative; boundary="Apple-Mail=_894A71C7-6DD4-480E-B6DF-1EDB63E8C52F" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52AB7BB6.2080002@gmail.com> Date: Fri, 13 Dec 2013 14:01:19 -0800 Message-Id: <8FD5ECFA-A4E6-484D-8A5C-F8C6BC1AEDCC@delong.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> <52AB4716.4040902@gmail.com> <52AB7BB6.2080002@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 13 Dec 2013 14:01:39 -0800 (PST) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:03:10 -0000 --Apple-Mail=_894A71C7-6DD4-480E-B6DF-1EDB63E8C52F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> I would think that the rational thing to do in an environment where >> you want to provide DHCP-PD and not other information via DHCP >> (which is hard for me to imagine why, but let's ignore that for the >> moment) would be to advertise an O bit and then answer with empty or >> negative responses for non PD requests. >=20 > Right - reset M, set O and answer negatively to non-PD DHCP requests. >=20 > But how about when the Delegated Prefix is available, > but via 'other other' means than DHCP such as Radius, or via PPP? = There > is no bit for that either. The 'O' and 'M' bits apply only to DHCP. There=92s no support for this, nor do I think I would expect there to be = support for this in RA. In the cases of PPP and RADIUS, you are already having an authentication = or other negotiation process with the server and I would presume that = there would be mechanisms in those negotiations to handle this. For = example, in RADIUS, the prefix(es) should be sent as additional = attribute/value pairs. In PPP, I presume it would be part of the IPCP6 = process, but I admit I haven=92t looked at those details. > It would be clearer if there were 1 bit for each of the fundamental > addressing aspects (address, default route, delegated prefix, etc.) = and > each would be 'O' - Address available by other means than this RA, > Default route available by other means than this RA, Delegated prefix > available by other means than this RA, etc. I don=92t see the advantage to this way of approaching it. Please = present a use case where this offers a clear advantage over the existing = mechanisms which would warrant an incompatible modification to everyone = else=92s expectations and existing software. Absent a compelling = advantage to such a change, I just don=92t think the risk/reward = proposition makes sesne. >> If you can't be sure the flows expired (easy with TCP, harder with >> other protocols), then you use the Valid timer and you're done. >=20 > I haven't seen this done elsewhere=85 The neighbor discovery RFC is pretty clear about it from my reading. = What is unique in what I propose is that you stop resetting the = client-side valid-time and desired-time timers when you receive a = service-side RA that would normally result in resetting them. However, = for renumbering the client side from 64share to delegated prefix, it = seems to me that it is very reasonable to immediately poison the desired = time and then withdraw the prefix from subsequent RAs. This will allow = the clients to preserve their existing flows until the valid timer = counts down to zero. The router can remove the prefix from the interface = at time +. Owen --Apple-Mail=_894A71C7-6DD4-480E-B6DF-1EDB63E8C52F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I would think = that the rational thing to do in an environment where
you want to = provide DHCP-PD and not other information via DHCP
(which is hard for = me to imagine why, but let's ignore that for the
moment) would be to = advertise an O bit and then answer with empty or
negative responses = for non PD requests.

Right - reset M, set O and = answer negatively to non-PD DHCP requests.

But how about when the = Delegated Prefix is available,
but via 'other other' means than DHCP = such as Radius, or via PPP?  There
is no bit for that either. =  The 'O' and 'M' bits apply only to = DHCP.

There=92s no support for = this, nor do I think I would expect there to be support for this in = RA.

In the cases of PPP and RADIUS, you are = already having an authentication or other negotiation process with the = server and I would presume that there would be mechanisms in those = negotiations to handle this. For example, in RADIUS, the prefix(es) = should be sent as additional attribute/value pairs. In PPP, I presume it = would be part of the IPCP6 process, but I admit I haven=92t looked at = those details.

It would be clearer if there were 1 bit = for each of the fundamental
addressing aspects (address, default = route, delegated prefix, etc.) and
each would be 'O' - Address = available by other means than this RA,
Default route available by = other means than this RA, Delegated prefix
available by other means = than this RA, etc.

I don=92t see = the advantage to this way of approaching it. Please present a use case = where this offers a clear advantage over the existing mechanisms which = would warrant an incompatible modification to everyone else=92s = expectations and existing software. Absent a compelling advantage to = such a change, I just don=92t think the risk/reward proposition makes = sesne.

If you can't = be sure the flows expired (easy with TCP, harder with
other = protocols), then you use the Valid timer and you're = done.

I haven't seen this done = elsewhere=85

The neighbor discovery RFC = is pretty clear about it from my reading. What is unique in what I = propose is that you stop resetting the client-side valid-time and = desired-time timers when you receive a service-side RA that would = normally result in resetting them. However, for renumbering the client = side from 64share to delegated prefix, it seems to me that it is very = reasonable to immediately poison the desired time and then withdraw the = prefix from subsequent RAs. This will allow the clients to preserve = their existing flows until the valid timer counts down to zero. The = router can remove the prefix from the interface at time = <t_last_ra_issued>+<valid_time_in_last_ra_issued>.
<= br>
Owen

= --Apple-Mail=_894A71C7-6DD4-480E-B6DF-1EDB63E8C52F-- From alexandru.petrescu@gmail.com Fri Dec 13 14:39:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953DA1AE41A; Fri, 13 Dec 2013 14:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.017 X-Spam-Level: X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyTh0L12y6Ac; Fri, 13 Dec 2013 14:39:56 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by ietfa.amsl.com (Postfix) with ESMTP id EBD461AE402; Fri, 13 Dec 2013 14:39:54 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 9DD9D4B0078; Fri, 13 Dec 2013 23:39:36 +0100 (CET) Message-ID: <52AB8CA6.9030402@gmail.com> Date: Fri, 13 Dec 2013 23:39:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> <52AB4716.4040902@gmail.com> <52AB7BB6.2080002@gmail.com> <8FD5ECFA-A4E6-484D-8A5C-F8C6BC1AEDCC@delong.com> In-Reply-To: <8FD5ECFA-A4E6-484D-8A5C-F8C6BC1AEDCC@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 131213-0, 13/12/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:39:58 -0000 On 13/12/2013 23:01, Owen DeLong wrote: >>> I would think that the rational thing to do in an environment >>> where you want to provide DHCP-PD and not other information via >>> DHCP (which is hard for me to imagine why, but let's ignore that >>> for the moment) would be to advertise an O bit and then answer >>> with empty or negative responses for non PD requests. >> >> Right - reset M, set O and answer negatively to non-PD DHCP >> requests. >> >> But how about when the Delegated Prefix is available, but via >> 'other other' means than DHCP such as Radius, or via PPP? There is >> no bit for that either. The 'O' and 'M' bits apply only to DHCP. > > There’s no support for this, Well... In addition to Radius and PPP, there are the migration v4-v6 mechanisms which may offer a v6 Delegated Prefix as well. > nor do I think I would expect there to be support for this in RA. But one _would_ expect RA to always be there. > In the cases of PPP and RADIUS, you are already having an > authentication or other negotiation process with the server and I > would presume that there would be mechanisms in those negotiations to > handle this. For example, in RADIUS, the prefix(es) should be sent as > additional attribute/value pairs. In PPP, I presume it would be part > of the IPCP6 process, but I admit I haven’t looked at those details. > >> It would be clearer if there were 1 bit for each of the >> fundamental addressing aspects (address, default route, delegated >> prefix, etc.) and each would be 'O' - Address available by other >> means than this RA, Default route available by other means than >> this RA, Delegated prefix available by other means than this RA, >> etc. > > I don’t see the advantage to this way of approaching it. Please > present a use case where this offers a clear advantage over the > existing mechanisms which would warrant an incompatible modification > to everyone else’s expectations and existing software. Absent a > compelling advantage to such a change, I just don’t think the > risk/reward proposition makes sesne. I agree. No particular use case. This is on the 'what-if' branch. Alex > >>> If you can't be sure the flows expired (easy with TCP, harder >>> with other protocols), then you use the Valid timer and you're >>> done. >> >> I haven't seen this done elsewhere… > > The neighbor discovery RFC is pretty clear about it from my reading. > What is unique in what I propose is that you stop resetting the > client-side valid-time and desired-time timers when you receive a > service-side RA that would normally result in resetting them. > However, for renumbering the client side from 64share to delegated > prefix, it seems to me that it is very reasonable to immediately > poison the desired time and then withdraw the prefix from subsequent > RAs. This will allow the clients to preserve their existing flows > until the valid timer counts down to zero. The router can remove the > prefix from the interface at time > +. > > Owen > --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com From owen@delong.com Fri Dec 13 15:02:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAAC1AE055; Fri, 13 Dec 2013 15:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYxIRKm2kLZr; Fri, 13 Dec 2013 15:02:33 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E211F1AE005; Fri, 13 Dec 2013 15:02:32 -0800 (PST) Received: from [50.94.79.230] ([50.94.79.230]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBDMvhGg025798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2013 14:57:44 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBDMvhGg025798 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1386975465; bh=7FYjlmBwQ/e7u1VZCO4UOlEgciU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=3d06KEqBSnY775/xeXW/8qmEQ4GFEko1JURji/lCAFCy6yvbHTz16/HtUJHUX2CXD 1d+Qkmr6JWKcZapUc4XO1v+xE60FLSl6E5Fy4e7n8GcsNSjX7kw2RTjf4Us2LgQ1yg EbkQj5cIUVd3n944AaR1JFgwtCmwrDyetxwPci1w= Content-Type: multipart/alternative; boundary="Apple-Mail=_143AB308-590E-4C7E-A8FB-7408BE895497" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52AB8CA6.9030402@gmail.com> Date: Fri, 13 Dec 2013 14:57:42 -0800 Message-Id: <608D5A72-9094-4A55-951A-6C876E0350A3@delong.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> <52AB4716.4040902@gmail.com> <52AB7BB6.2080002@gmail.com> <8FD5ECFA-A4E6-484D-8A5C-F8C6BC1AEDCC@delong.com> <52AB8CA6.9030402@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 13 Dec 2013 14:57:45 -0800 (PST) Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 23:02:35 -0000 --Apple-Mail=_143AB308-590E-4C7E-A8FB-7408BE895497 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 13, 2013, at 2:39 PM, Alexandru Petrescu = wrote: > On 13/12/2013 23:01, Owen DeLong wrote: >>>> I would think that the rational thing to do in an environment >>>> where you want to provide DHCP-PD and not other information via >>>> DHCP (which is hard for me to imagine why, but let's ignore that >>>> for the moment) would be to advertise an O bit and then answer >>>> with empty or negative responses for non PD requests. >>>=20 >>> Right - reset M, set O and answer negatively to non-PD DHCP >>> requests. >>>=20 >>> But how about when the Delegated Prefix is available, but via >>> 'other other' means than DHCP such as Radius, or via PPP? There is >>> no bit for that either. The 'O' and 'M' bits apply only to DHCP. >>=20 >> There=92s no support for this, >=20 > Well... >=20 > In addition to Radius and PPP, there are the migration v4-v6 = mechanisms which may offer a v6 Delegated Prefix as well. Examples, please? >> nor do I think I would expect there to be support for this in RA. >=20 > But one _would_ expect RA to always be there. The ubiquitous presence of RA doesn=92t mean that we should bloat those = RAs with a bit for every conceivable possible choice of configuration = mechanism that some person might want to use in some obscure = application. Indeed, I would argue that it means quite the opposite, = that we should be very judicious in what kind of bloat we stuff into = RAs. RDNSS had a pretty compelling case, IMHO. Short of an equally compelling = case, I really don=92t think it=92s worth the tradeoffs. >=20 >> In the cases of PPP and RADIUS, you are already having an >> authentication or other negotiation process with the server and I >> would presume that there would be mechanisms in those negotiations to >> handle this. For example, in RADIUS, the prefix(es) should be sent as >> additional attribute/value pairs. In PPP, I presume it would be part >> of the IPCP6 process, but I admit I haven=92t looked at those = details. >>=20 >>> It would be clearer if there were 1 bit for each of the >>> fundamental addressing aspects (address, default route, delegated >>> prefix, etc.) and each would be 'O' - Address available by other >>> means than this RA, Default route available by other means than >>> this RA, Delegated prefix available by other means than this RA, >>> etc. >>=20 >> I don=92t see the advantage to this way of approaching it. Please >> present a use case where this offers a clear advantage over the >> existing mechanisms which would warrant an incompatible modification >> to everyone else=92s expectations and existing software. Absent a >> compelling advantage to such a change, I just don=92t think the >> risk/reward proposition makes sesne. >=20 > I agree. >=20 > No particular use case. This is on the 'what-if' branch. What-ifs are all well and good, but if you want to create the kind of = protocol upheaval that you are suggesting, then I think more than = what-ifs are necessary. I think that would require a very compelling use = case. Owen --Apple-Mail=_143AB308-590E-4C7E-A8FB-7408BE895497 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 13, 2013, at 2:39 PM, Alexandru = Petrescu <alexandru.petrescu@gmail.com<= /a>> wrote:

On 13/12/2013 23:01, Owen DeLong = wrote:
I would think that the rational thing to do in an = environment
where you want to provide DHCP-PD and not other = information via
DHCP (which is hard for me to imagine why, but let's = ignore that
for the moment) would be to advertise an O bit and then = answer
with empty or negative responses for non PD = requests.

Right - reset M, set O and answer = negatively to non-PD DHCP
requests.

But how about when the = Delegated Prefix is available, but via
'other other' means than DHCP = such as Radius, or via PPP?  There is
no bit for that either. =  The 'O' and 'M' bits apply only to = DHCP.

There=92s no support for = this,

Well...

In addition to Radius and PPP, = there are the migration v4-v6 mechanisms which may offer a v6 Delegated = Prefix as well.

Examples, = please?



In the = cases of PPP and RADIUS, you are already having an
authentication or = other negotiation process with the server and I
would presume that = there would be mechanisms in those negotiations to
handle this. For = example, in RADIUS, the prefix(es) should be sent as
additional = attribute/value pairs. In PPP, I presume it would be part
of the = IPCP6 process, but I admit I haven=92t looked at those = details.

It would be clearer if there = were 1 bit for each of the
fundamental addressing aspects (address, = default route, delegated
prefix, etc.) and each would be 'O' - = Address available by other
means than this RA, Default route = available by other means than
this RA, Delegated prefix available by = other means than this RA,
etc.

I don=92t see the = advantage to this way of approaching it. Please
present a use case = where this offers a clear advantage over the
existing mechanisms = which would warrant an incompatible modification
to everyone else=92s = expectations and existing software. Absent a
compelling advantage to = such a change, I just don=92t think the
risk/reward proposition makes = sesne.

I agree.

No particular use case. =  This is on the 'what-if' = branch.

What-ifs are all well and = good, but if you want to create the kind of protocol upheaval that you = are suggesting, then I think more than what-ifs are necessary. I think = that would require a very compelling use = case.


= --Apple-Mail=_143AB308-590E-4C7E-A8FB-7408BE895497-- From sthaug@nethelp.no Fri Dec 13 22:56:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D941AE146 for ; Fri, 13 Dec 2013 22:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x1U9vL5arcs for ; Fri, 13 Dec 2013 22:56:38 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id EDE541AE4EB for ; Fri, 13 Dec 2013 22:56:37 -0800 (PST) Received: (qmail 65689 invoked from network); 14 Dec 2013 06:56:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 14 Dec 2013 06:56:28 -0000 Date: Sat, 14 Dec 2013 07:56:28 +0100 (CET) Message-Id: <20131214.075628.74686573.sthaug@nethelp.no> To: alexandru.petrescu@gmail.com From: sthaug@nethelp.no In-Reply-To: <52AB8CA6.9030402@gmail.com> References: <52AB7BB6.2080002@gmail.com> <8FD5ECFA-A4E6-484D-8A5C-F8C6BC1AEDCC@delong.com> <52AB8CA6.9030402@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, v6ops@ietf.org Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 06:56:42 -0000 > In addition to Radius and PPP, there are the migration v4-v6 mechanisms > which may offer a v6 Delegated Prefix as well. > > > nor do I think I would expect there to be support for this in RA. > > But one _would_ expect RA to always be there. Not necessarily. Some of us would like to use DHCPv6 for this, and be rid of RA. Yes, I'm very much aware that this isn't supported today, Steinar Haug, AS 2116 From alexandru.petrescu@gmail.com Sat Dec 14 03:42:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0AF1ADF80; Sat, 14 Dec 2013 03:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.017 X-Spam-Level: X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-lwwoxR2pUE; Sat, 14 Dec 2013 03:42:30 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by ietfa.amsl.com (Postfix) with ESMTP id B57E11ADF8F; Sat, 14 Dec 2013 03:41:19 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id F3E97A6332; Sat, 14 Dec 2013 12:41:02 +0100 (CET) Message-ID: <52AC43CB.8000404@gmail.com> Date: Sat, 14 Dec 2013 12:40:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Owen DeLong References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> <52AB4716.4040902@gmail.com> <52AB7BB6.2080002@gmail.com> <8FD5ECFA-A4E6-484D-8A5C-F8C6BC1AEDCC@delong.com> <52AB8CA6.9030402@gmail.com> <608D5A72-9094-4A55-951A-6C876E0350A3@delong.com> In-Reply-To: <608D5A72-9094-4A55-951A-6C876E0350A3@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 131213-0, 13/12/2013), Outbound message X-Antivirus-Status: Clean Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 11:42:31 -0000 On 13/12/2013 23:57, Owen DeLong wrote: > > On Dec 13, 2013, at 2:39 PM, Alexandru Petrescu > > > wrote: > >> On 13/12/2013 23:01, Owen DeLong wrote: >>>>> I would think that the rational thing to do in an >>>>> environment where you want to provide DHCP-PD and not other >>>>> information via DHCP (which is hard for me to imagine why, >>>>> but let's ignore that for the moment) would be to advertise >>>>> an O bit and then answer with empty or negative responses for >>>>> non PD requests. >>>> >>>> Right - reset M, set O and answer negatively to non-PD DHCP >>>> requests. >>>> >>>> But how about when the Delegated Prefix is available, but via >>>> 'other other' means than DHCP such as Radius, or via PPP? >>>> There is no bit for that either. The 'O' and 'M' bits apply >>>> only to DHCP. >>> >>> There’s no support for this, >> >> Well... >> >> In addition to Radius and PPP, there are the migration v4-v6 >> mechanisms which may offer a v6 Delegated Prefix as well. > > Examples, please? 64rd for example. And Prefix Delegation for Mobile IPv6 based on DHCPv6 over a tunnel. And I guess IKE as well may provide a Delegated Prefix (just a guess). >>> nor do I think I would expect there to be support for this in >>> RA. >> >> But one _would_ expect RA to always be there. > > The ubiquitous presence of RA doesn’t mean that we should bloat those > RAs with a bit for every conceivable possible choice of > configuration mechanism that some person might want to use in some > obscure application. I agree. But I said just the fundamental addressing aspects, those common parameters involved in most basic setups. And, the bits wouldn't be tied to one particular protocol (DHCP) but to any Other protocols. The 'O's would mean any Other, not just any Other DHCP. > Indeed, I would argue that it means quite the opposite, that we > should be very judicious in what kind of bloat we stuff into RAs. Right, bloat should be avoided. This could be done by this Other word, and by the RA flags expansion option anyways (existing RFC). > RDNSS had a pretty compelling case, IMHO. Short of an equally > compelling case, I really don’t think it’s worth the tradeoffs. I agree. >>> In the cases of PPP and RADIUS, you are already having an >>> authentication or other negotiation process with the server and >>> I would presume that there would be mechanisms in those >>> negotiations to handle this. For example, in RADIUS, the >>> prefix(es) should be sent as additional attribute/value pairs. In >>> PPP, I presume it would be part of the IPCP6 process, but I admit >>> I haven’t looked at those details. >>> >>>> It would be clearer if there were 1 bit for each of the >>>> fundamental addressing aspects (address, default route, >>>> delegated prefix, etc.) and each would be 'O' - Address >>>> available by other means than this RA, Default route available >>>> by other means than this RA, Delegated prefix available by >>>> other means than this RA, etc. >>> >>> I don’t see the advantage to this way of approaching it. Please >>> present a use case where this offers a clear advantage over the >>> existing mechanisms which would warrant an incompatible >>> modification to everyone else’s expectations and existing >>> software. Absent a compelling advantage to such a change, I just >>> don’t think the risk/reward proposition makes sesne. >> >> I agree. >> >> No particular use case. This is on the 'what-if' branch. > > What-ifs are all well and good, but if you want to create the kind of > protocol upheaval that you are suggesting, then I think more than > what-ifs are necessary. I think that would require a very compelling > use case. I agree. Alex > > Owen > --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com From bs7652@att.com Sat Dec 14 08:27:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8491AE049; Sat, 14 Dec 2013 08:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtVA8uMugZJG; Sat, 14 Dec 2013 08:27:34 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 773BF1AE202; Sat, 14 Dec 2013 08:11:37 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 3338ca25.2b274ac3d940.3545766.00-2475.9217883.nbfkord-smmo07.seg.att.com (envelope-from ); Sat, 14 Dec 2013 16:11:31 +0000 (UTC) X-MXL-Hash: 52ac833361e49cd5-2919575bc6e6021f0cc7ffd497d82e578a54e5c6 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 1338ca25.0.3545762.00-2298.9217868.nbfkord-smmo07.seg.att.com (envelope-from ); Sat, 14 Dec 2013 16:11:30 +0000 (UTC) X-MXL-Hash: 52ac83322ac844ea-2cd5044a69ccea0c19d9e83bd7124ba8875b83d2 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBEGBRF4002073; Sat, 14 Dec 2013 11:11:28 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBEGBMjP002029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Dec 2013 11:11:23 -0500 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi131.aldc.att.com (RSA Interceptor); Sat, 14 Dec 2013 16:11:06 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.03.0158.001; Sat, 14 Dec 2013 11:11:05 -0500 From: "STARK, BARBARA H" To: Alexandru Petrescu , Owen DeLong Thread-Topic: IA_PD bit in RA Thread-Index: AQHO+B39SvUpHwxAj06AY53zq4J+/JpSp0wAgAARwACAAAmwAIAANQwAgADWBHA= Date: Sat, 14 Dec 2013 16:11:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303B23F9@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <52A83C92.4020204@gmail.com> <52A9A93F.8050804@gmail.com> <9CB9D172-BA78-492B-B836-D7A9C6CB11A5@delong.com> <52AAEDDA.6010504@gmail.com> <52AB318C.2050704@gmail.com> <52AB4716.4040902@gmail.com> <52AB7BB6.2080002@gmail.com> In-Reply-To: <52AB7BB6.2080002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.100.252] 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-AnalysisOut: [v=2.0 cv=Qo7pKyOd c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=wOnn6M8j7YsA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=YThoL1SpN] X-AnalysisOut: [okA:10 a=tuhTHUYCW2_tny44x9UA:9 a=CjuIK1q_8ugA:10 a=75XkpT] X-AnalysisOut: [237SpN9S8V:21 a=bOVNlqePzCV_I-qy:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Cc: "v6ops@ietf.org" , 6man WG Subject: Re: [v6ops] IA_PD bit in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 16:27:45 -0000 X-List-Received-Date: Sat, 14 Dec 2013 16:27:45 -0000 > But how about when the Delegated Prefix is available, but via 'other othe= r' > means than DHCP such as Radius, or via PPP? There is no bit for that eit= her. > The 'O' and 'M' bits apply only to DHCP. PPP is at a lower layer than IP. PPP clients are specifically configured to= establish PPP (with PPP login and password). Once PPP is established, the = client can try to establish IPv6 per RFC5072. This uses IPV6CP to negotiate= the interface identifier of the client's WAN interface, which can then be = used to construct the IPv6 Link-local address of this interface. RFC7084 references that PPP may be established below IP (WLL-2, WLL-3). Onc= e that link-local address exists on the PPP link, the RFC7084-compliant CE = router sets up the rest of IPv6 exactly as it does for IPv6 directly over E= thernet (with RS/RA [though it's ok for there to be no RA since default rou= te is the PPP link; but try it anyway in case there's a SLAAC prefix], DHCP= v6). This is also consistent with BBF TR-124. The goal was to minimize the = number of different ways of doing the same thing that would need to be code= d in a CE router. I can't address networks that might do RADIUS directly from the CE router, = because I'm not familiar with any such networks. BBF TR-177 and TR-187 do s= upport using RADIUS in the access network, but the CE router doesn't know t= his. The access network can pick up the CE router's authentication paramete= rs from access line identification information in the RS (inserted by the a= ccess node, and not the CE router) or from PPP. Since the CE router has no = concept of RADIUS, it's not possible for it to do something different in re= sponse to RADIUS. I'd like to keep it this way. I think it's very good that there are no special RA bits for PPP or RADIUS. Barbara From lorenzo@google.com Sun Dec 15 22:50:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30DF1AE2BA for ; Sun, 15 Dec 2013 22:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2Vy87UOcabA for ; Sun, 15 Dec 2013 22:50:14 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CE0C11AE2BF for ; Sun, 15 Dec 2013 22:50:14 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id j1so3146672iga.2 for ; Sun, 15 Dec 2013 22:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5/FRozGMee4uNCSw9KKhEUACkHhV9DB2r9ovK9RoEDA=; b=MmlNQb+pczm7l6yZ0oJmAj/LGYfvUEfjpoEXRFxehymTK3fhSLlvrMhIGXtjJDBSbY OwLJMjj0bhcM1j6mLjwwQb79mmrdT/A+DwD0+kzAc233np04z6JJJGJ+W35N0CjAjPo4 pC6gF3eZrYnt3jUEYQDzt8FAbiWKsapobKpbkApFP+H5vZtR+pqLwiyKcyAJZHKuPgik ofXiwphFUQwKirHSrbIsTRO0WZrTg4teJrfK6AiHx0OAS76PfvjGHTfjxk5d+eL3GXCj vOVUeyPfyfiNRBecxzYs3lZVaaMR6NgbJ+Rik/Mkb07V6T62mEOxy930DJPeYsMq4Per bg5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5/FRozGMee4uNCSw9KKhEUACkHhV9DB2r9ovK9RoEDA=; b=Bl89ocSdXDu58S5BXmRDuRPPuMRbj1gvlymOk32ZF/2xw55sjcXcb2q4V3ceAsktaa 7y3IH/uqcOcY4H2H1edrIeX4LvkEsXTcWrw5o3tdgGJf2vB/9dE6hKsh1W87f58NqcXI m1JH1J4cQvTI7dmuBD+mHQsBbm3fU4/u8W6qaidrICWpa25BCEtWotYzA0bT+UL+jkMe emDf/T05v6jW2YYeEw6n4wODGE3X8E0Jxwyzp1+QiqWLaW3v2dDqq7sEPcUeQOOcEHcY tL+wgadxwswp6C30HkUuojXj4v6cp+VqmTdez4bHogYUi1Nz8ABtad4FQHGG2Lylkmh/ YSyg== X-Gm-Message-State: ALoCoQn9e6LeX7AqVH/D+6N11YYKA3gfwLtmjfLNa3jwS6rbZju1AZCAsY7s3K8oM7Yy2i76oX8KmySoEINrugumQKjsQv7oZzvZMaFNG337h6wrklT0EIEJMeGynec3MpmAOwqm7BRalDqIXsyxeuVXGOjfIQ13dcDpJOrZMU5vLNO6FFkZXhrFymeVW6ZEQu0m5Pnq4vW1 X-Received: by 10.43.98.202 with SMTP id cp10mr10929163icc.28.1387176614137; Sun, 15 Dec 2013 22:50:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sun, 15 Dec 2013 22:49:54 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 16 Dec 2013 15:49:54 +0900 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=bcaec517191153b73404eda13961 Cc: v6ops Subject: Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 06:50:21 -0000 --bcaec517191153b73404eda13961 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 2:04 AM, Dan Wing wrote: > ICE is not only useful for NAT traversal, but also firewall traversal for > both IPv4 and IPv6. That is, ICE (or NAT-PMP, or UPnP IGD, or PCP) is > needed if the IPv6 network has simple security (RFC6092). > Actually it isn't necessarily needed. If two parties establish a bidirectional stream (which in the case of a voice or video call they will), then each endpoint's outgoing packets to the other endpoint will punch a hole in its firewall that allows the other endpoint's packets to come in, and you don't need ICE for anything. --bcaec517191153b73404eda13961 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 12, 2013 at 2:04 AM, Dan Wing <dwing@cisco.com> wrote:=
ICE is not only useful for NA= T traversal, but also firewall traversal for both IPv4 and IPv6. =A0That is= , ICE (or NAT-PMP, or UPnP IGD, or PCP) is needed if the IPv6 network has s= imple security (RFC6092).

Actually it isn't necessarily ne= eded.

If two parties establish a bidirectional str= eam (which in the case of a voice or video call they will), then each endpo= int's outgoing packets to the other endpoint will punch a hole in its f= irewall that allows the other endpoint's packets to come in, and you do= n't need ICE for anything.
--bcaec517191153b73404eda13961-- From lorenzo@google.com Sun Dec 15 23:11:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F501A802D for ; Sun, 15 Dec 2013 23:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHaYLSaj2EFK for ; Sun, 15 Dec 2013 23:11:06 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8A59E1AE13F for ; Sun, 15 Dec 2013 23:11:06 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id k19so3158089igc.1 for ; Sun, 15 Dec 2013 23:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VY+ERQ6X/Ed7mKG98PvYckFiAuEFj7Un73DCCjnD9pM=; b=CufZglDpUWa9Eq/kOG8U7XbmQ87k7+5u3EKilfywjLb9PAeIZWx7rjJEMZtNOpFM6A Kiq8e3SZSnTGk7+K20PY9+S/BhOaxJOnIIdz/131v95qcSYc9aJ7IjsHgUnKiVd09MR5 AoI3Vd8HvCZJpJIfbpflClqsvi26zpZAIZuOHnEHz3P8mHkSJ782pBLjwGj50IfEtcgK VqK0CtxFFW/qyIg30YnT/dGY9czQ9i1+4OBm2aFhGLJRfKTOsyth355wN7MUiLVo7deV UBusmRjTPrPpErinL3SUDpFvn5yfMmQ1VgbXXajzHE/qHfqsSNPCdCK0j3heEnXEMKr4 /Zyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VY+ERQ6X/Ed7mKG98PvYckFiAuEFj7Un73DCCjnD9pM=; b=mXFNJIBEiaP0sWmKwinV+Av69lg216hsWTXKqm1rvPU87LOweYZyhWN7YLRPzl8i4X lavInVUv3PVFKQ6dFAE7Xe2Fa8Rh4izIE/6fbBz0LeVjgT3fUdpTx8bFUEzsrIAcyLju rFciPFcSDM33PeSfHS6+DGfAo+20TM3lF2hawSMyozJrxqkYqS9Wl0YwAQyRCT/TYS5G uLtcedCRmAKBSp0R4ZG3BS+yJD4gz10J5TbR65ZQq537fQuwrFDwm1w9Vfp5V96ljByl ZtoRbGyq7v172X2F8HoDOi40qp9X63P+SKZ1Htd5FHta5TUmJ2Asp0ol2KSPibZJUAxB c5Gg== X-Gm-Message-State: ALoCoQmzO60SiRd/LG7RpQOdob26O84Pd9+Ul0yRX+yyh8bmznouvTb6R+kjm8CDDiwq18TEKuDpGjWQKDER6Hbes594KAu9/RCXJbexa7LasiCNm100dZBT+SwUYQSbxxzC+F3g+uS5JTrMK4tdvny2ZlE/+FG5io5OmaqzbOTXdpogTqdmVlEYU2fpXQkUOt6gftCQDa7X X-Received: by 10.43.81.200 with SMTP id zz8mr10651477icb.29.1387177865843; Sun, 15 Dec 2013 23:11:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sun, 15 Dec 2013 23:10:45 -0800 (PST) In-Reply-To: <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> From: Lorenzo Colitti Date: Mon, 16 Dec 2013 16:10:45 +0900 Message-ID: To: "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Content-Type: multipart/alternative; boundary=bcaec517cb72ef3ed904eda1833f Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 07:11:08 -0000 --bcaec517cb72ef3ed904eda1833f Content-Type: text/plain; charset=ISO-8859-1 I notice that this draft cites draft-ietf-v6ops-ula-usage-recommendations , which is still under discussion. I assume that means that even if this document passes IETF last call and IESG review, it cannot be published as an RFC until draft-ietf-v6ops-ula-usage-recommendations is ready to be published. The citation of draft-ietf-v6ops-ula-usage-recommendations doesn't seem to be used for any particular purpose, it just seems to be mentioned in passing. Authors - if you want this document to be published quickly, you might want to remove the citation On Thu, Dec 12, 2013 at 2:52 AM, Fred Baker (fred) wrote: > Folks: we have been around this block several times, and I'd like to bring > it to closure. This updates addresses comments raised in a WGLC in > September. My objective is to determine whether there are any remaining > issues, and if not, send it to the IESG. I would like to *not* find issues > in the IETF WGLC coming from this community - I really want to deal with > these here. So... > > let's take until 20 December to discuss this - WGLC. > > On Dec 8, 2013, at 7:37 PM, 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 Operations Working Group of the > IETF. > > > > Title : NAT64 Operational Experience > > Author(s) : Gang Chen > > Zhen Cao > > Chongfeng Xie > > David Binet > > Filename : draft-ietf-v6ops-nat64-experience-05.txt > > Pages : 21 > > Date : 2013-12-08 > > > > Abstract: > > This document summarizes NAT64 function deployment scenarios and > > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and > > NAT64 server Front End (NAT64-FE) are considered in this document. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-05 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --bcaec517cb72ef3ed904eda1833f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I notice that this draft cites= =A0draft-ietf-v6ops-ula-usage-recommendations , which is still under discus= sion. I assume that means that even if this document passes IETF last call = and IESG review, it cannot be published as an RFC until=A0draft-ietf-v6ops-= ula-usage-recommendations is ready to be published.

The citatio= n of=A0draft-ietf-v6ops-ula-usage-recommendations doesn't seem to be us= ed for any particular purpose, it just seems to be mentioned in passing. Au= thors - if you want this document to be published quickly, you might want t= o remove the citation

On Thu, Dec 12, 2013 at 2:52 AM, Fred Baker = (fred) <fred@cisco.com> wrote:
Folks: we have been around this block several times, and I'd like to br= ing it to closure. This updates addresses comments raised in a WGLC in Sept= ember. My objective is to determine whether there are any remaining issues,= and if not, send it to the IESG. I would like to *not* find issues in the = IETF WGLC coming from this community - I really want to deal with these her= e. So...

let's take until 20 December to discuss this - WGLC.

On Dec 8, 2013, at 7:37 PM, int= ernet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IPv6 Operations Working Group of the = IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : NAT64 Operational Experience > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Gang Chen
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Zhen Cao
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Chongfeng Xie
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0David Binet
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-nat64-experienc= e-05.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-08
>
> Abstract:
> =A0 This document summarizes NAT64 function deployment scenarios and > =A0 operational experience. =A0Both NAT64 Carrier Grade NAT (NAT64-CGN= ) and
> =A0 NAT64 server Front End (NAT64-FE) are considered in this document.=
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6op= s-nat64-experience
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-e= xperience-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-v6ops-nat64-experience-05
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--bcaec517cb72ef3ed904eda1833f-- From fred@cisco.com Sun Dec 15 23:49:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0968E1AE17F for ; Sun, 15 Dec 2013 23:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.039 X-Spam-Level: X-Spam-Status: No, score=-110.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxIjaYaS-hyp for ; Sun, 15 Dec 2013 23:49:26 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8D41AE0D9 for ; Sun, 15 Dec 2013 23:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4544; q=dns/txt; s=iport; t=1387180165; x=1388389765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pJuLXft1u9Lq6jiWS3oY/Sos+llUF+T6z+NUPL02ikQ=; b=mVF9NECYqENx9TdEtedqO8jJbBlep/h0AiiNVQ3SRlvZHIyuhABDy7q2 PFsPJob3KFgKQVUbqL3xo3f9YwgwcF9JJc4AEelxisJPTAhshvd1xgjn2 baFvYo7fepWVAFJo5hjk7qfKAtT0dNcWTxVS87kCLDiFcqRfUZ6RyK7uC o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGewrlKtJXHA/2dsb2JhbABZgwo4Twa4ZYEeFnSCJQEBAQMBAQEBZAcLBQsCAQgYLicLJQIEDgUJBQaHaAgIBcc4F48ZBwmDGoETBJAzgTGGMoEwkGSDKoIq X-IronPort-AV: E=Sophos;i="4.95,493,1384300800"; d="asc'?scan'208";a="7003753" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 16 Dec 2013 07:49:25 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBG7nPNd005745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 07:49:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 01:49:24 -0600 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt Thread-Index: AQHO+jNWq54qTR94JEaiLnfjre67Zg== Date: Mon, 16 Dec 2013 07:49:24 +0000 Message-ID: <7468AC73-6B83-41A3-B961-A815443CF6D6@cisco.com> References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_FBFECC06-5574-4E37-ACB0-6A16B304766C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 07:49:29 -0000 --Apple-Mail=_FBFECC06-5574-4E37-ACB0-6A16B304766C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 15, 2013, at 11:10 PM, Lorenzo Colitti = wrote: > I notice that this draft cites = draft-ietf-v6ops-ula-usage-recommendations , which is still under = discussion. I assume that means that even if this document passes IETF = last call and IESG review, it cannot be published as an RFC until = draft-ietf-v6ops-ula-usage-recommendations is ready to be published. >=20 > The citation of draft-ietf-v6ops-ula-usage-recommendations doesn't = seem to be used for any particular purpose, it just seems to be = mentioned in passing. Authors - if you want this document to be = published quickly, you might want to remove the citation True for normative references; this is informative, which the argument = doesn't hold for. The statement in the draft is Unique Local Addresses (ULAs) are defined in [RFC4193] to be renumbered within a network site for local communications. Operators may use ULAs as NAT64 prefixes to provide site-local IPv6 connectivity. Those ULA prefixes are stripped when the packets going to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site. The use of ULAs could help in identifying the translation traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided further guidance for the ULAs usages. what, specifically, is your objection? > On Thu, Dec 12, 2013 at 2:52 AM, Fred Baker (fred) = wrote: > Folks: we have been around this block several times, and I'd like to = bring it to closure. This updates addresses comments raised in a WGLC in = September. My objective is to determine whether there are any remaining = issues, and if not, send it to the IESG. I would like to *not* find = issues in the IETF WGLC coming from this community - I really want to = deal with these here. So... >=20 > let's take until 20 December to discuss this - WGLC. >=20 > On Dec 8, 2013, at 7:37 PM, internet-drafts@ietf.org wrote: >=20 > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the IPv6 Operations Working Group of = the IETF. > > > > Title : NAT64 Operational Experience > > Author(s) : Gang Chen > > Zhen Cao > > Chongfeng Xie > > David Binet > > Filename : draft-ietf-v6ops-nat64-experience-05.txt > > Pages : 21 > > Date : 2013-12-08 > > > > Abstract: > > This document summarizes NAT64 function deployment scenarios and > > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) = and > > NAT64 server Front End (NAT64-FE) are considered in this document. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-05 > > > > A diff from the previous version is available at: > > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-05 > > > > > > Please note that it may take a couple of minutes from the time of = submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein --Apple-Mail=_FBFECC06-5574-4E37-ACB0-6A16B304766C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSrrCCbjEdbHIsm0MRAn7wAKDOXHOvBnbaTsAfLRG0O50iYaDpFACeLJJE uH5sJDjMn7517nRYdcRlgd0= =w/KV -----END PGP SIGNATURE----- --Apple-Mail=_FBFECC06-5574-4E37-ACB0-6A16B304766C-- From lorenzo@google.com Sun Dec 15 23:55:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0611AE2D4 for ; Sun, 15 Dec 2013 23:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZnJiW0belmv for ; Sun, 15 Dec 2013 23:55:21 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 35F571AE2D3 for ; Sun, 15 Dec 2013 23:55:21 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id k19so3215515igc.1 for ; Sun, 15 Dec 2013 23:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NSTBZ0iFE29uOoB6D3odCrCF9RJ4uUt9tdEcUjKzfVI=; b=CjJCRxdhK4YZBiW2IK8qiNAZ2av142Jy0OUslVvc0yPz9kjgDJTxPmTPt6L/hLC3H1 bdsjjJ1ckGbAezhpIyNpymgcyIcMTY6X0XjxxUiEufoY8GkH4gLW1RRHgjpFsV6LhbV4 7Cl5SAdhfSKr5AnodGLC3QMdeMGhKFJqxI0OI+nLtEM/ZFz+0RlUEyg+NzpjpCtvsx+X i7rj7zYYEqNcO+rcYFblzuFvAmwEFpAyXjEIxwUKg4+o3iLVDO3qDQjJvlQaq9Xc4g+j anFbz2DYAicD7de2TP7GJYt2rSVfZ/XRzMYX6zdsT/B8FRZuyjUm/3J9A8a0+UaiK7cv IZtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NSTBZ0iFE29uOoB6D3odCrCF9RJ4uUt9tdEcUjKzfVI=; b=bGDm4oh5jiS67wsU7MyqtQjPGD1RszrMdMtkqmqwfe8q0iYpGsmuZuJEWgoWxsv53r B2ohJGi+j8KAxa4h5hkQLGwUQEZOyVbIFKSVaQ5MkBksHv4i6PCrMvrAR8pOuqY4zAGr Ta9iuZ1tqZHgfg5YsyfAyxz93OKtzZOLSu8IebtaaoMjsgdu20X6w7gzHpi7d0SiN+KV 5zKW3oXBip3J760TTsJJWRcf7n3CPHd9hv8c6dYgeeOkhoCcl4O09og0kSoUXRgZTgZt t9lwHWZxe9/VJm24Kh4chxAH3w0j8vOEJzZrpgTgFEA+ko5ZN5XYXQ9yRrBkIjwAsyS0 Gl0Q== X-Gm-Message-State: ALoCoQnzqsm58KMSS2ot6XhbmOyfm1vOwZKrt4kvkv1V3xgb28Sv05cfTsJCjUC0PwfsG07uRe31GslTaA9MthL8FYgxovrO1TLyQYgZ0tHSxxUPm0lr9E+0fJ6PyIC1l1gDAtBiHkhpRQsvqdLScbYMsYa1oNiGZ0fOVVaOlBIwVJORW2HqjR9Z9FesLLoOx8jG+eC4T1W5 X-Received: by 10.50.61.137 with SMTP id p9mr13998726igr.45.1387180520538; Sun, 15 Dec 2013 23:55:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sun, 15 Dec 2013 23:55:00 -0800 (PST) In-Reply-To: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> From: Lorenzo Colitti Date: Mon, 16 Dec 2013 16:55:00 +0900 Message-ID: To: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7bdca5dc2aac8204eda22266 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 07:55:27 -0000 --047d7bdca5dc2aac8204eda22266 Content-Type: text/plain; charset=ISO-8859-1 A few comments: 1. The draft should note that per RFC 6434 (IPv6 node requirements), hosts MUST support SLAAC, but are not required to support DHCPv6, since it's a SHOULD (and note that until relatively recently - December 2011 - it was a MAY). So while a network administrator can reasonably assume that SLAAC will be supported by hosts, he cannot assume that DHCPv6 will be supported. 2. The statement in Section 2.1.1 that "when A flag is set, the SLAAC protocol didn't provide a prescriptive definition" is incorrect. RFC 4862 says that if A=0 the host should "silently ignore the Prefix Information option", and if A=1 "form an address" (bullet point d) or "the preferred lifetime of the address is reset [...]" (bullet point e). Both rules MUST be enabled by default, as clearly stated in RFC 4862 section 5.5. 3. In section 3.3 it's not clear why "the administrator wants the hosts to do DHCPv6-only configuration". All hosts that support DHCPv6 will do DHCPv6-only if A=0 and M=1. Hosts that don't support DHCPv6... won't be able to do DHCPv6-only regardless of what the administrator wants them to do. On Wed, Dec 4, 2013 at 10:45 PM, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Please > take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7bdca5dc2aac8204eda22266 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A few comments:

1. The draft should not= e that per RFC 6434 (IPv6 node requirements), hosts MUST support SLAAC, but= are not required to support DHCPv6, since it's a SHOULD (and note that= until relatively recently - December 2011 - it was a MAY). So while a netw= ork administrator can reasonably assume that SLAAC will be supported by hos= ts, he cannot assume that DHCPv6 will be supported.

2. The statement in Section 2.1.1 that "when A fla= g is set, the SLAAC protocol didn't provide a prescriptive definition&q= uot; is incorrect.

RFC 4862 says that if A=3D0 the= host should "silently ignore the Prefix Information option", and= if A=3D1 "form an address" (bullet point d) or "the preferr= ed lifetime of the address is reset [...]" (bullet point e). Both rule= s MUST be enabled by default, as clearly stated in RFC 4862 section 5.5.

3. In section 3.3 it's not clear why "the admi= nistrator wants the hosts to do DHCPv6-only configuration". All hosts = that support DHCPv6 will do DHCPv6-only if A=3D0 and M=3D1. Hosts that don&= #39;t support DHCPv6... won't be able to do DHCPv6-only regardless of w= hat the administrator wants them to do.


On Wed,= Dec 4, 2013 at 10:45 PM, <fred@cisco.com> wrote:

A new draft has been posted, at http://tools.ietf.org/h= tml/draft-ietf-v6ops-dhcpv6-slaac-problem. Please take a look at it and= comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7bdca5dc2aac8204eda22266-- From lorenzo@google.com Sun Dec 15 23:58:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF2D1AE2D4 for ; Sun, 15 Dec 2013 23:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9U3K-00Mjli for ; Sun, 15 Dec 2013 23:58:37 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 48E931AE2D3 for ; Sun, 15 Dec 2013 23:58:37 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so5995792ieb.22 for ; Sun, 15 Dec 2013 23:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mjuXJHA1IxMAxhIpDsaYTYMErsL4WpR+0t2uxjH7WZI=; b=e1UPyD/SVo7cFgY+pCQdUThyECHiLiU7ZAbp/Ol3VCIc5UBB8LP2bLs1/u5sIjM8Mw PwMj+lt7PEZ7/SnLZTd9Al6TuvAF4ypezQz18QIhCGijsgcX4BiJ0F3qCy6EuBtYQ1/F JbBnpDGxh4hrTW3Y+sWEZ+ANXWMq4xv6yROqag/I6N2YikEpdX6adw+TyPNTCAxWTz4X AJupI4VFVxcTtwkOb2Ib5+MOIGzZC5PQrIp+V+TNH7UwUZQl9G3rKea5aWg0lwM2mgfc VREVBkO730o0hkBVea7iUX4hKYk9+t9NlMJVVESBWMrHvslOVg87BTtmsLUZzKuXTjIx Lluw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mjuXJHA1IxMAxhIpDsaYTYMErsL4WpR+0t2uxjH7WZI=; b=Of2agIdJiUZcRmqCAQWCiCQVSkvTFNR8RfimYI5ixL0AbWjjHwK10AYCqqkQg0CRwH ARgUPQswga8H+LoBLfGBtPV7VNh+Ci2juix/s+AVeXz3Fe6w3P6/kXV6WMdJ+4Agq5yv eUuIDQS6EehEpUiSw7Bm4BLk9o1Nqm4HvxH/bQ4qhqytQUEUGjsJB6IXLoUxojTb3YiR DJIUNuWNyHDvV+5Rdiy6jW7wtl7Du1/4qdg3NVGDItao6gW9sM15zLNRXYA7tTjTP7Sw Zkioqvpey4gYzAiSbVm+L93+qBjbRt/7nDweLDARhi811OSYut3RbysP7pnRsA8jPEl+ ZCWQ== X-Gm-Message-State: ALoCoQl/Mxjl1GSjGCyP9PBaLwagiFvIQkBCk0n73zEbeTM5QwNsNw8vBP8ClcqJT9vcsm1ByeRuvw+mGFNLfaE7As2ia1JBvsHssdYmkjC3mgR9fGRC4ToroPQnfPaHGWKI7y+7XW+1zfh8li3eOeh69O6oySfiVPVBAh1ZN7rV5Fs/xrEtsamdW64EvywD+v4lw5aMk/k8 X-Received: by 10.50.41.38 with SMTP id c6mr13188018igl.47.1387180716603; Sun, 15 Dec 2013 23:58:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Sun, 15 Dec 2013 23:58:16 -0800 (PST) In-Reply-To: <7468AC73-6B83-41A3-B961-A815443CF6D6@cisco.com> References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> <7468AC73-6B83-41A3-B961-A815443CF6D6@cisco.com> From: Lorenzo Colitti Date: Mon, 16 Dec 2013 16:58:16 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e0117689fda607b04eda22d34 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 07:58:41 -0000 --089e0117689fda607b04eda22d34 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 16, 2013 at 4:49 PM, Fred Baker (fred) wrote: > True for normative references; this is informative, which the argument > doesn't hold for. > > The statement in the draft is > > Unique Local Addresses (ULAs) are defined in [RFC4193] to be > renumbered within a network site for local communications. Operators > may use ULAs as NAT64 prefixes to provide site-local IPv6 > connectivity. Those ULA prefixes are stripped when the packets going > to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site. > The use of ULAs could help in identifying the translation > traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided > further guidance for the ULAs usages. > > what, specifically, is your objection? > I was referring to the text "[I-D.ietf-v6ops-ula-usage-recommendations] has provided further guidance for the ULAs usages.". That document is not an RFC yet, and I thought that it was inappropriate to cite it from other RFCs. If you're saying that's not an issue, then that's fine. That said, I think the document shouldn't say "has provided further guidance" because we don't yet know what guidance will be. If anything it should say "provides further guidance". --089e0117689fda607b04eda22d34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 16, 2013 at 4:49 PM, Fred Baker (fred) <fred@cisco.com>= wrote:
True= for normative references; this is informative, which the argument doesn= 9;t hold for.

The statement in the draft is

=A0 =A0Unique Local Addresses (ULAs) are defined in [RFC4193] to be
=A0 =A0renumbered within a network site for local communications. =A0Operat= ors
=A0 =A0may use ULAs as NAT64 prefixes to provide site-local IPv6
=A0 =A0connectivity. =A0Those ULA prefixes are stripped when the packets go= ing
=A0 =A0to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site= .
=A0 =A0The use of ULAs could help in identifying the translation
=A0 =A0traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided
=A0 =A0further guidance for the ULAs usages.

what, specifically, is your objection?

= I was referring to the text "[I-D.ietf-v6ops-ula-usage-recommendations= ] has provided
=A0 =A0further guidance for the ULAs usages."= . That document is not an RFC yet, and I thought that it was inappropriate = to cite it from other RFCs. If you're saying that's not an issue, t= hen that's fine.

That said, I think the document shouldn't say "= ;has provided further guidance" because we don't yet know what gui= dance will be. If anything it should say "provides further guidance&qu= ot;.
--089e0117689fda607b04eda22d34-- From lorenzo@google.com Mon Dec 16 02:48:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C524F1AE19C for ; Mon, 16 Dec 2013 02:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYHPGwCTJ1Am for ; Mon, 16 Dec 2013 02:48:53 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1740D1AE1B0 for ; Mon, 16 Dec 2013 02:48:53 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id hk11so3491828igb.0 for ; Mon, 16 Dec 2013 02:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=FB/oxZCdXbRKx4tcUTGalxqrIH+kKMCo8r1YTkm1E20=; b=ksc4e/7tJyl9RIMGKs8FT2XXFhKad8YppZPiTvSHXQh+dGAZcrVeS3Gox8cEnh2tqo dKX/S9GdDWoV0g7Nmx7Aq+Ao+vdX2uoinfvKEbFTmUFyj9U9QTMj9tK/OCoffIUeXhgh 9lP1ilN6njRKPSnl3QDMjdplFAk6MrMtCeBnHIcgZOckj9Q5Q6JMrWsJ995fWpg1lSh9 YoPlS0uzH6e766wvwWMJN+4oIwX0ddyojclQa5P/sRff7DxDAcwiNhwRYODnhWtY30Uw R7sif4HEI0Ctk4hldwyKZcAWYEu/18YA5Oka2hLLzWemuTDzdent4Cqb1azViydha9TE hx9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=FB/oxZCdXbRKx4tcUTGalxqrIH+kKMCo8r1YTkm1E20=; b=gLBYY/DhSAqFss9H6hhge59JwDsiGsFk557TmGhOppZ0zqbcUd/3CehOFIAM+857Mx CXB2KNxntgaXLLrA3if0YbMvdilyFuDSbAhTbQE5K4+VbRLFqQoh2B+4c8uhirZNN87c fAAzyKuxw+imh7pTJSQdHum+bQ6Xv4dEXKaKKDB9pvYIjcsHgPLZYl0yIDHdDVAJp0hs xeaN1xc3n5LMA7OoiG2oWvu0i3jHE7Dlc/Fdl0IAOQ7hWZyMb0Gc4pykF4sl33Nsif4b KK8Nmjq4v6Bt/+os1iqkasRiaY1i0vO7+yjmDbmMMkl9EcB36V3m5tcjPeG4nB+QXK4i wEoQ== X-Gm-Message-State: ALoCoQluO5g4qczhaOP/SZkAb/AjQnlajH7Zv0WZbjRgQ3vyAgQhgAB6RlRBun8SZoU22uYTMjO7kKuDIszgUex+6KzlJ34fGtAsu+YjNoPHaOdYlbJ+6gBCFwdIkV+5sskzgHaE1ywyKs0BLJVfeUaZC+igNKfEPkV+8YPyv7e2nYDA4Sl8kKedVXFGJorn3usxA9pwSIuJ X-Received: by 10.50.56.38 with SMTP id x6mr14048953igp.31.1387190932312; Mon, 16 Dec 2013 02:48:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Mon, 16 Dec 2013 02:48:30 -0800 (PST) From: Lorenzo Colitti Date: Mon, 16 Dec 2013 19:48:30 +0900 Message-ID: To: Yourtchenko Andrew Content-Type: multipart/alternative; boundary=089e0158b05ec1b3db04eda48e4f Cc: "v6ops@ietf.org WG" Subject: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 10:48:58 -0000 --089e0158b05ec1b3db04eda48e4f Content-Type: text/plain; charset=ISO-8859-1 Andrew, finally found the time to put down some thoughts on this. First, I think the goal ("How do I know which of the two to use") is not what we should aim for, at least initially, because it's too controversial. I think that at least initially, what we should try to achieve is a comparison of the properties of the protocols themselves, not make recommendations of which to use. If we agree on the properties, then later on we might be able to make recommendations, but I think even agreeing on the properties will be quite a bit of work. Second: some of the text you have now deals with link-layer performance. However, I think that since these are configuration protocols, the attributes that are important are primarily semantics, not performance or implementation. So we should focus on the information that the protocols are able to express rather than the mechanics of how they express it. For example: "an RA is a multicast packet" is an implementation detail, but "an RA can update configuration information even if it's sent by a different entity than the one that sent the original RA" is a semantic property. Third: there's a lot of text here that could be seen as subjective or a value judgment. I think a document like this is more likely to reach consensus if a lot of the text is removed and each section starts from the basic properties of the protocols, which are hopefully less subject to disagreement. With that in mind: 1. There's a lot of controversial and non-objective text here. I think a lot of it should be deleted, and the section should be stripped down to saying that: - Current IPv4 deployments use only DHCP - IPv6 was designed to use RA for connectivity and addressing, which has semantic differences. - Other IPv6 parameters can only be configured via DHCPv6 - That this document aims to describe the properties of the two protocols 2.1. I think this section should be removed. There is basically no difference between RA with unicast reply and DHCPv6 - both are a multicast solicit and a unicast reply. It's true that the DHCPv6 client retries more, but draft-ietf-6man-resilient-rs is making RAs use the same retry algorithm. It's also true that an RA also causes periodic multicasts, but the frequency of those multicasts is entirely under the control of the operator. It's true that sending solicited RAs multicast is a waste of bandwidth, but that's not a feature of the protocol itself, it's a feature of the implementation. 2.3. I think this is mostly incorrect. In practice, RA also needs two packets. Also, "you have to take care that it is legitimate router" applies to DHCPv6 just as well as RA, and the solution is the same - RA/DHCP guard. 2.4 I don't understand the point here. What are you trying to say? Compare scaling properties between RA and DHCP on a busy network? 2.5. I would suggest "configuration" instead of "control". You should also note that this can be done via unicast RA as well. 2.6. - I think we should stay away from "good" and "bad". Just stick to the facts. Less to argue about later. - Where you say "a router can spoof another router" - that affects DHCP and RA in the same way, and the solution is the same - RA/DHCP guard. 2.7. You should note that stateless DHCP cannot configure addresses. (And perhaps also that stateful is the basic mode of DHCPv6 operation). 2.8. I don't we should attempt to reach consensus on what to use the protocols for. It's true that DHCPv6 cannot currently configure routing, and multiple attempts to make it to do so have failed due to lack of consensus. However, I think we should just avoid considerations about whether this should be possible or not, because that isn't a property of the protocol, it's a question about what we decide to do with the protocol. Instead, I'd stick to the protocol properties, which as I see them are: - RAs have to be sent out by the routers themselves, which make them a bit more robust with respect to misconfiguration than DHCP. In DHCP, the server might be several hops away might not know what routers are on the link, or the server entry could be typo'd. It's true that this doesn't happen often in IPv4, but I think that's mostly because people scream when it does. Fate sharing avoids this problem entirely. - To a large extent, RAs share fate with the routers that send them; for example, if a router loses power, then it will stop sending RAs. It's true that we address both of these in IPv4, but typically we do so by using protocols like VRRP. 2.10. The current text seems to say that the implementation work is roughly equal, and since implementations aren't written very often, it's not really as important as the properties of the protocols themselves. So I don't think this section ads much. 2.11. I'm not sure this section is fit for an RFC :) 2.12. I don't think it's realistic to try to get consensus on this initially. Perhaps later :) 2.13. I think what people mostly want here is address tracking (i.e., "who had this IP address at this time?"). In a case where the network wants to know what addresses have been requested by hosts, then using DHCP for address assignment makes this easy because all you need to do is look at the server logs. However, this in itself is not secure, because the host could just pick another of the 2^64 addresses on the subnet and use that. To make it secure, the router must watch address registrations and enforce that unregistered addresses can't send packets. So you need first-hop security too. Once you have first-hop security, you don't necessarily need to use DHCP though - you can do it for SLAAC and manually-configured addresses as well. Finally, a couple of things you don't mention: - If you want hosts to be able to use a number of different IPv6 addresses (e.g., to change them periodically for privacy, or to use different addresses for different apps or different destinations), you can't do that with DHCPv6. - In fact, I don't think DHCPv6 can be used to assign multiple addresses (more than 2) to a host at all. Can it? - In DHCPv6, if the server crashes there's no way to update the information in the client, because RECONFIGURE requires a DHCPv6 nonce that only the server has. - It might be worth mentioning that SLAAC is a MUST in the host requirements, and DHCPv6 is A SHOULD. Not sure. Cheers, Lorenzo --089e0158b05ec1b3db04eda48e4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andrew,

finally found the ti= me to put down some thoughts on this.

First, I thi= nk the goal ("How do I know which of the two to use") is not what= we should aim for, at least initially, because it's too controversial.= I think that at least initially, what we should try to achieve is a compar= ison of the properties of the protocols themselves, not make recommendation= s of which to use. If we agree on the properties, then later on we might be= able to make recommendations, but I think even agreeing on the properties = will be quite a bit of work.

Second: some of the text you have now deals with link-l= ayer performance. However, I think that since these are configuration proto= cols, the attributes that are important are primarily semantics, not perfor= mance or implementation. So we should focus on the information that the pro= tocols are able to express rather than the mechanics of how they express it= . For example: "an RA is a multicast packet" is an implementation= detail, but "an RA can update configuration information even if it= 9;s sent by a different entity than the one that sent the original RA"= is a semantic property.

Third: there's a lot of text here that could be see= n as subjective or a value judgment. I think a document like this is more l= ikely to reach consensus if a lot of the text is removed and each section s= tarts from the basic properties of the protocols, which are hopefully less = subject to disagreement.


With that in mind:

<= div>
1. There's a lot of controversial and non-objective = text here. I think a lot of it should be deleted, and the section should be= stripped down to saying that:

- Current IPv4 deployments use only DHCP
- IP= v6 was designed to use RA for connectivity and addressing, which has semant= ic differences.
- Other IPv6 parameters can only be configured vi= a DHCPv6
- That this document aims to describe the properties of the two protoc= ols


2.1. I think this section shoul= d be removed. There is basically no difference between RA with unicast repl= y and DHCPv6 - both are a multicast solicit and a unicast reply. It's t= rue that the DHCPv6 client retries more, but draft-ietf-6man-resilient-rs i= s making RAs use the same retry algorithm. It's also true that an RA al= so causes periodic multicasts, but the frequency of those multicasts is ent= irely under the control of the operator. It's true that sending solicit= ed RAs multicast is a waste of bandwidth, but that's not a feature of t= he protocol itself, it's a feature of the implementation.=A0

2.3. I think this is mostly incorrect. In practice, RA = also needs two packets. Also, "you have to take care that it is legiti= mate router" applies to DHCPv6 just as well as RA, and the solution is= the same - RA/DHCP guard.

2.4 I don't understand the point here. What are you= trying to say? Compare scaling properties between RA and DHCP on a busy ne= twork?

2.5. I would suggest "configuration&qu= ot; instead of "control". You should also note that this can be d= one via unicast RA as well.

2.6.
- I think we should stay away from "= ;good" and "bad". Just stick to the facts. Less to argue abo= ut later.
- Where you say "a router can spoof another router= " - that affects DHCP and RA in the same way, and the solution is the = same - RA/DHCP guard.

2.7. You should note that stateless DHCP cannot configu= re addresses. (And perhaps also that stateful is the basic mode of DHCPv6 o= peration).

2.8. I don't we should attempt to r= each consensus on what to use the protocols for. It's true that DHCPv6 = cannot currently configure routing, and multiple attempts to make it to do = so have failed due to lack of consensus. However, I think we should just av= oid considerations about whether this should be possible or not, because th= at isn't a property of the protocol, it's a question about what we = decide to do with the protocol. Instead, I'd stick to the protocol prop= erties, which as I see them are:

- RAs have to be sent out by the routers themselves, wh= ich make them a bit more robust with respect to misconfiguration than DHCP.= In DHCP, the server might be several hops away might not know what routers= are on the link, or the server entry could be typo'd. It's true th= at this doesn't happen often in IPv4, but I think that's mostly bec= ause people scream when it does. Fate sharing avoids this problem entirely.=
- To a large extent, RAs share fate with the routers that send them; f= or example, if a router loses power, then it will stop sending RAs. It'= s true that we address both of these in IPv4, but typically we do so by usi= ng protocols like VRRP.

2.10. The current text seems to say that the implementa= tion work is roughly equal, and since implementations aren't written ve= ry often, it's not really as important as the properties of the protoco= ls themselves. So I don't think this section ads much.

2.11. I'm not sure this section is fit for an= RFC :)

2.12. I don't think it's realistic= to try to get consensus on this initially. Perhaps later :)

2.13. I think what people mostly want here is address tracki= ng (i.e., "who had this IP address at this time?"). In a case whe= re the network wants to know what addresses have been requested by hosts, t= hen using DHCP for address assignment makes this easy because all you need = to do is look at the server logs. However, this in itself is not secure, be= cause the host could just pick another of the 2^64 addresses on the subnet = and use that. To make it secure, the router must watch address registration= s and enforce that unregistered addresses can't send packets. So you ne= ed first-hop security too. Once you have first-hop security, you don't = necessarily need to use DHCP though - you can do it for SLAAC and manually-= configured addresses as well.


Finally, a couple of things you don'= t mention:

- If you want hosts to be able to use a= number of different IPv6 addresses (e.g., to change them periodically for = privacy, or to use different addresses for different apps or different dest= inations), you can't do that with DHCPv6.
- In fact, I don't think DHCPv6 can be used to assign multip= le addresses (more than 2) to a host at all. Can it?
- In DHCPv6,= if the server crashes there's no way to update the information in the = client, because RECONFIGURE requires a DHCPv6 nonce that only the server ha= s.
- It might be worth mentioning that SLAAC is a MUST in the host requir= ements, and DHCPv6 is A SHOULD. Not sure.

Chee= rs,
Lorenzo
--089e0158b05ec1b3db04eda48e4f-- From ayourtch@cisco.com Mon Dec 16 05:42:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26911AE327 for ; Mon, 16 Dec 2013 05:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BBl36NxV34k for ; Mon, 16 Dec 2013 05:42:16 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 957881AE323 for ; Mon, 16 Dec 2013 05:42:16 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBGDgFwM022396 for ; Mon, 16 Dec 2013 14:42:15 +0100 (CET) Received: from [10.61.167.202] ([10.61.167.202]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBGDgA2x013222; Mon, 16 Dec 2013 14:42:11 +0100 (CET) Date: Mon, 16 Dec 2013 13:42:09 +0000 (WET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Lorenzo Colitti In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 13:42:20 -0000 Lorenzo, First: thanks for the very detailed and specific comments, given that this is probably the biggest change, I've decided to get it in first before the other pending updates. (Sander's comments were in so I mostly took care of them as well). The latest head on github reflects this. There're some questions/comments though, inline below. On Mon, 16 Dec 2013, Lorenzo Colitti wrote: > Andrew, > > finally found the time to put down some thoughts on this. > > First, I think the goal ("How do I know which of the two to use") is not what we should aim for, at least initially, because > it's too controversial. I think that at least initially, what we should try to achieve is a comparison of the properties of > the protocols themselves, not make recommendations of which to use. If we agree on the properties, then later on we might be > able to make recommendations, but I think even agreeing on the properties will be quite a bit of work. Yes, I think it certainly makes sense. > > Second: some of the text you have now deals with link-layer performance. However, I think that since these are configuration > protocols, the attributes that are important are primarily semantics, not performance or implementation. So we should focus on > the information that the protocols are able to express rather than the mechanics of how they express it. For example: "an RA > is a multicast packet" is an implementation detail, but "an RA can update configuration information even if it's sent by a > different entity than the one that sent the original RA" is a semantic property. Yes, especially that the lower layers can and do create abstractions with different underlying properties. > > Third: there's a lot of text here that could be seen as subjective or a value judgment. I think a document like this is more > likely to reach consensus if a lot of the text is removed and each section starts from the basic properties of the protocols, > which are hopefully less subject to disagreement. Yes, I think the approach of pretty much direct pasting of the text from the conversation has proven to be wrong. > > > With that in mind: > > > 1. There's a lot of controversial and non-objective text here. I think a lot of it should be deleted, and the section should > be stripped down to saying that: > > - Current IPv4 deployments use only DHCP I suppose I also mention RFC 1256 which was defined, but not adopted ? > - IPv6 was designed to use RA for connectivity and addressing, which has semantic differences. > - Other IPv6 parameters can only be configured via DHCPv6 uhm two immediate counter-examples: RDNSS & individual address assignments. > - That this document aims to describe the properties of the two protocols > yup. > > 2.1. I think this section should be removed. There is basically no difference between RA with unicast reply and DHCPv6 - both > are a multicast solicit and a unicast reply. It's true that the DHCPv6 client retries more, but draft-ietf-6man-resilient-rs > is making RAs use the same retry algorithm. It's also true that an RA also causes periodic multicasts, but the frequency of > those multicasts is entirely under the control of the operator. It's true that sending solicited RAs multicast is a waste of > bandwidth, but that's not a feature of the protocol itself, it's a feature of the implementation. > done. > 2.3. I think this is mostly incorrect. In practice, RA also needs two packets. Also, "you have to take care that it is > legitimate router" applies to DHCPv6 just as well as RA, and the solution is the same - RA/DHCP guard. I was trying to say that RA works, albeit degraded, with one packet only. DHCP does not. Edited to have it captured better. I've removed the security-related stuff - Sander mentioned it earlier as well, fully agree. > > 2.4 I don't understand the point here. What are you trying to say? Compare scaling properties between RA and DHCP on a busy > network? 2 things: - you can initiate either protocol from either side - RA protocol, due to one-to-many approach, is much harder to cause snowball-type of failure (where your central device has to queue packets to process them, and then the queued packets go out of date, so the clients retransmit, retransmits get queued, etc.) > > 2.5. I would suggest "configuration" instead of "control". You should also note that this can be done via unicast RA as well. > The latest text says "coordination": I did not want to write "configuration", because the RA does not configure the address, rather the prefix. Also: unicast RAs with per-client info ? > 2.6. > - I think we should stay away from "good" and "bad". Just stick to the facts. Less to argue about later. yup. removed. > - Where you say "a router can spoof another router" - that affects DHCP and RA in the same way, and the solution is the same - > RA/DHCP guard. I was trying to emphasize the operation after you have received your address. With DHCP, your vulnerability window is during the initial address assignment. With RA - all the time. > > 2.7. You should note that stateless DHCP cannot configure addresses. ack. > (And perhaps also that stateful is the basic mode of > DHCPv6 operation). "first defined" != "basic". There's RFC3736 which specifically describes just stateless-only mode of operation. It's only 9 pages. > > 2.8. I don't we should attempt to reach consensus on what to use the protocols for. It's true that DHCPv6 cannot currently > configure routing, and multiple attempts to make it to do so have failed due to lack of consensus. However, I think we should > just avoid considerations about whether this should be possible or not, because that isn't a property of the protocol, it's a > question about what we decide to do with the protocol. Instead, I'd stick to the protocol properties, which as I see them are: > > - RAs have to be sent out by the routers themselves, which make them a bit more robust with respect to misconfiguration than > DHCP. In DHCP, the server might be several hops away might not know what routers are on the link, or the server entry could be > typo'd. It's true that this doesn't happen often in IPv4, but I think that's mostly because people scream when it does. Fate > sharing avoids this problem entirely. > - To a large extent, RAs share fate with the routers that send them; for example, if a router loses power, then it will stop > sending RAs. It's true that we address both of these in IPv4, but typically we do so by using protocols like VRRP. Yeah this was the section with a massive copypaste which I still had to edit, and the discussion was a bit emotional, and I think this layout summarizes the essence well. So I put it in with very very light editing and deleted the rest. > > 2.10. The current text seems to say that the implementation work is roughly equal, and since implementations aren't written > very often, it's not really as important as the properties of the protocols themselves. So I don't think this section ads > much. > I think it's worth keeping, at least for the time being, since it provides what I think as at least one useful pointer to RFC3542 ? > 2.11. I'm not sure this section is fit for an RFC :) Wait, we can't have L8 considerations ?!? :-) deleted. > > 2.12. I don't think it's realistic to try to get consensus on this initially. Perhaps later :) +1. It's gone. > > 2.13. I think what people mostly want here is address tracking (i.e., "who had this IP address at this time?"). In a case > where the network wants to know what addresses have been requested by hosts, then using DHCP for address assignment makes this > easy because all you need to do is look at the server logs. Yes, totally agree here. > However, this in itself is not secure, because the host could just > pick another of the 2^64 addresses on the subnet and use that. To make it secure, the router must watch address registrations > and enforce that unregistered addresses can't send packets. So you need first-hop security too. Once you have first-hop > security, you don't necessarily need to use DHCP though - you can do it for SLAAC and manually-configured addresses as well. Yes, totally agree here as well. That's what I also say. But, immediately after saying that I think that in the bigger picture of things, this imperfection of the "common wizdom" status quo may be a blessing. > > > Finally, a couple of things you don't mention: > > - If you want hosts to be able to use a number of different IPv6 addresses (e.g., to change them periodically for privacy, or > to use different addresses for different apps or different destinations), you can't do that with DHCPv6. You can, at least in the standard - RFC3315 defines IA_TA precisely for this: Identity association for temporary addresses (IA_TA) An IA that carries temporary addresses (see RFC 3041 [12]). > - In fact, I don't think DHCPv6 can be used to assign multiple addresses (more than 2) to a host at all. Can it? RFC3315, beginning of page 73: An IA_NA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_NA options. This to me implies the DHCP can be used to assign multiple non-temporary addresses. > - In DHCPv6, if the server crashes there's no way to update the information in the client, because RECONFIGURE requires a > DHCPv6 nonce that only the server has. I've mentioned it earlier in the text: in the scenario of the DHCPv6 server sending the RECONFIGURE message to the client, DHCPv6 server must keep some knowledge of the client - which means it might need to keep some state. But I've added this: Thus if there is a requirement to keep the ability for the DHCPv6 server infrastructure to retain the ability of sending the RECONFIGURE message, this state needs to be kept across the server crashes and reboots. > - It might be worth mentioning that SLAAC is a MUST in the host requirements, and DHCPv6 is A SHOULD. Not sure. Thanks! I added to "Asymmetric external standards requirements" section. (as well as renamed this section to not have "external" in it). --a > > Cheers, > Lorenzo > > From Ted.Lemon@nominum.com Mon Dec 16 05:49:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F781ADFC4 for ; Mon, 16 Dec 2013 05:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4jkaDOAwSxs for ; Mon, 16 Dec 2013 05:49:07 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5821ADFC2 for ; Mon, 16 Dec 2013 05:49:07 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUq8E0nvhc7Szcy89bPNx6CqOe9WcIZiR@postini.com; Mon, 16 Dec 2013 05:49:06 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7BE471B82E2 for ; Mon, 16 Dec 2013 05:49:06 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 52E21190043; Mon, 16 Dec 2013 05:49:06 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Dec 2013 05:49:06 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Mon, 16 Dec 2013 08:49:01 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 13:49:08 -0000 On Dec 16, 2013, at 5:48 AM, Lorenzo Colitti wrote: > I think that at least initially, what we should try to achieve is a = comparison of the properties of the protocols themselves, not make = recommendations of which to use.=20 +1 > Second: some of the text you have now deals with link-layer = performance. However, I think that since these are configuration = protocols, the attributes that are important are primarily semantics, = not performance or implementation. Lorenzo, this is kind of a puzzling position to take. There are lots = of ways to do things with really nice semantics that fall on their face = for performance reasons. So I think performance questions are in = scope. Thanks for the thorough review! From ayourtch@cisco.com Mon Dec 16 06:09:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1997E1AE32A for ; Mon, 16 Dec 2013 06:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVymUnw4ObNO for ; Mon, 16 Dec 2013 06:09:09 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A7A221ADFE5 for ; Mon, 16 Dec 2013 06:09:08 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBGE97fM025274 for ; Mon, 16 Dec 2013 15:09:07 +0100 (CET) Received: from [10.61.167.202] ([10.61.167.202]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBGE93cH023590; Mon, 16 Dec 2013 15:09:04 +0100 (CET) Date: Mon, 16 Dec 2013 14:09:01 +0000 (WET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Ted Lemon In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:09:10 -0000 On Mon, 16 Dec 2013, Ted Lemon wrote: > On Dec 16, 2013, at 5:48 AM, Lorenzo Colitti wrote: >> I think that at least initially, what we should try to achieve is a comparison of the properties of the protocols themselves, not make recommendations of which to use. > +1 > >> Second: some of the text you have now deals with link-layer performance. However, I think that since these are configuration protocols, the attributes that are important are primarily semantics, not performance or implementation. > > Lorenzo, this is kind of a puzzling position to take. There are lots >of ways to do things with really nice semantics that fall on their face >for performance reasons. So I think performance questions are in scope. Ted, I've taken the interaction with the underlying levels out for now: pragmatically, it reduces the number of things to have the consensus on (assuming that there is a consensus that we need to have a consensus :). When/if we discover that everyone's in violent agreement, we add them back. What do you think ? --a From lorenzo@google.com Mon Dec 16 06:13:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDBF1AE34A for ; Mon, 16 Dec 2013 06:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of8wYffndgIe for ; Mon, 16 Dec 2013 06:13:13 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCB91AE33D for ; Mon, 16 Dec 2013 06:13:13 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id uq10so3847475igb.0 for ; Mon, 16 Dec 2013 06:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YzqTb1be7+MnEVsy2vDJoVknsiVnWnqf0YmYjrsGb3c=; b=PpAG0H47mdT7T7F0OtKoX1NvXOtvBD9QaRHvFpaBbRLiJox7PpaN2vNFvI4vywEr22 C6VfAfGXGuA/Or9kxT/K+xd1SGr1zDJOeCZ0qQJeBX+HtI86VQ5TDfescAdx0yo+YZ6o mclcctAWk+TyD7fFfRW/0RmGa8NV39kZ+ZoG9B8Ml8PgP1VMnyL3Ij3yv54oxFpIFOLg JhMMI+0fOB5bITQW/7Pt7+/Tl8MUkEjFYHSJ2hJOtOh0F36PqrrMYr9st/iE1XMKzlqg Syx2kTypCQNHgMJG0Ju6Sd/zyc6OVHeDYRAcViHaOsbl/auYXHE4HY+7hllPsZdndY// VJtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YzqTb1be7+MnEVsy2vDJoVknsiVnWnqf0YmYjrsGb3c=; b=dXncFCv2BCAbcKLmwqJSB5CcbeI9OPq+pRX2fh96ca52Sps2v1IvbIyrRGd+4stLQL v7kpMIHpeTGgTn5oRMjllV+QEKBp70QOBpvU+a3ynVQtB1jFGeaXHN8vOaPvCUG63uCs ySNXQepsUCc9nKcNqQsbHQUSI/Bilo9CYZa51YfqrIA83DHmEQptxV5RcrwrjPxmNRHX iywnf0cGTMDJIkO2yC9+xWUGbFRgUUiV+W93Z7qGmUOjpuvMUKHZDebFBXMexlx7ps5c bLQ842DnACG/R1jAd9FPxYdIwv2gB8XPkm0HNYvnwC2LjePGOaiW8eM/CJ/N0Rd6hk80 IcrQ== X-Gm-Message-State: ALoCoQmR3mattD6ZCdg8wQG29dhfQi4xNR90fpDVns4KztO3kpzUZnxYF2Xhf+56OWmdFBdaGKCHeWKInxQ6cCSgap0XriZzNZ7wPOSgoO3cU0nSq4B8Yjxjv6K+aDLq+tvkvyu0VQohHc8FcCkEQiFZ+7li4OTcVnYOok18xlxnI9Iaql3zWG/MFcpAMOFHUtD9sKDreYlR X-Received: by 10.43.81.200 with SMTP id zz8mr11880540icb.29.1387203192562; Mon, 16 Dec 2013 06:13:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Mon, 16 Dec 2013 06:12:52 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 16 Dec 2013 23:12:52 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec517cb72865c5d04eda76970 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:13:14 -0000 --bcaec517cb72865c5d04eda76970 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 16, 2013 at 10:49 PM, Ted Lemon wrote: > > Second: some of the text you have now deals with link-layer performance. > However, I think that since these are configuration protocols, the > attributes that are important are primarily semantics, not performance or > implementation. > > Lorenzo, this is kind of a puzzling position to take. There are lots of > ways to do things with really nice semantics that fall on their face for > performance reasons. So I think performance questions are in scope. > Oh, of course - in general, they are. But here the protocols used are so similar that there is little substantive difference in performance. --bcaec517cb72865c5d04eda76970 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 16, 2013 at 10:49 PM, Ted Lemon <ted.lemon@nominum.com>= wrote:
> Second: some of the t= ext you have now deals with link-layer performance. However, I think that s= ince these are configuration protocols, the attributes that are important a= re primarily semantics, not performance or implementation.

Lorenzo, this is kind of a puzzling position to take. =A0 There are l= ots of ways to do things with really nice semantics that fall on their face= for performance reasons. =A0 So I think performance questions are in scope= .

Oh, of course - in general, they are. But = here the protocols used are so similar that there is little substantive dif= ference in performance.
--bcaec517cb72865c5d04eda76970-- From otroan@employees.org Mon Dec 16 06:25:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2B51ADFFE for ; Mon, 16 Dec 2013 06:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMWPBuH7n7lt for ; Mon, 16 Dec 2013 06:25:08 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD9F1ADFF2 for ; Mon, 16 Dec 2013 06:25:08 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAHsMr1KQ/khL/2dsb2JhbABZgwq5foEmFnSCJQEBBAF5EAtGVwaIDwiwLZdIF45LTgeDI4ETAQOQM5l3gys7 X-IronPort-AV: E=Sophos;i="4.95,495,1384300800"; d="asc'?scan'208";a="1706171" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 16 Dec 2013 14:25:06 +0000 Received: from dhcp-10-61-106-87.cisco.com (dhcp-10-61-106-87.cisco.com [10.61.106.87]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBGEP6hd011683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 14:25:06 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_ABA9F5F4-BC7A-49E8-B5AE-D45245E0536F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Mon, 16 Dec 2013 15:25:05 +0100 Message-Id: <94433006-8AF6-45ED-B247-03EC1B397356@employees.org> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:25:09 -0000 --Apple-Mail=_ABA9F5F4-BC7A-49E8-B5AE-D45245E0536F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Lorenzo, > > Second: some of the text you have now deals with link-layer = performance. However, I think that since these are configuration = protocols, the attributes that are important are primarily semantics, = not performance or implementation. >=20 > Lorenzo, this is kind of a puzzling position to take. There are lots = of ways to do things with really nice semantics that fall on their face = for performance reasons. So I think performance questions are in = scope. >=20 > Oh, of course - in general, they are. But here the protocols used are = so similar that there is little substantive difference in performance. could you expand on that? I see the scaling properties on a multicast capable link very different = between the two. take a multicast capable link with 10K nodes on it, where power has just = come back. a few hundred RS/RA messages, at least 40K DHCPv6 messages. cheers, Ole --Apple-Mail=_ABA9F5F4-BC7A-49E8-B5AE-D45245E0536F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSrw1BAAoJEFuJXizso86gjDwIAJH2/7JsvneRD05xvHcCWUzQ ZAQRRxrnq/GpNdOljd0SR3xFXpBR/vAydHwjxczvfN7/kEMjtHbuUKgI5fYBbLbP ngRo0J/olKxW8niidk7iA1jn5lV9+SqSCFRAnzSdHkaXGxOAyhfi8+GRXg0v5pRY CY/bdoMykQLxfGUjf0G+hGpXibbu63Y5uAPDsQ6hmuQn4i8tQv91bzZyfTtjnwgo QJEeakymzV7OEJPaQgPXGeSVApM5sHP9OTQCMRMEIe0fUio+yelsQDNkUIRywM8u +DoTEzQ2ALUS2ZREC06B7miuZXamio5WDqtjWjvrDrbSzGJTHS0KBpQr/EXx5AY= =rrsc -----END PGP SIGNATURE----- --Apple-Mail=_ABA9F5F4-BC7A-49E8-B5AE-D45245E0536F-- From Ted.Lemon@nominum.com Mon Dec 16 06:46:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B06A1ADFFA for ; Mon, 16 Dec 2013 06:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OWyp2u5gAa9 for ; Mon, 16 Dec 2013 06:46:37 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id ABD3D1ADFDD for ; Mon, 16 Dec 2013 06:46:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUq8STZLlZJXuGaHLnpmdsDkVMJf1AkKZ@postini.com; Mon, 16 Dec 2013 06:46:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0B30F1B82D9 for ; Mon, 16 Dec 2013 06:46:37 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DB57F190043; Mon, 16 Dec 2013 06:46:36 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Dec 2013 06:46:36 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Mon, 16 Dec 2013 09:46:31 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <411BFDB9-101D-4FC5-9A81-35140F8F5643@nominum.com> References: To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:46:39 -0000 On Dec 16, 2013, at 9:09 AM, Andrew Yourtchenko = wrote: > When/if we discover that everyone's in violent agreement, we add them = back. What do you think ? Sure. I don't mean to pressure you to add or remove anything=97I just = think it's worth mentioning substantive performance issues, of which = some exist. It's definitely not worth listing anything that is = controversial=97I think there are some known performance issues that = everybody agrees exist, and I think those are arguably worth mentioning. But if you think the document stands without them, that's fine with me = too. From simon.perreault@viagenie.ca Mon Dec 16 08:11:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545591AE354 for ; Mon, 16 Dec 2013 08:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMO1EUlLRNon for ; Mon, 16 Dec 2013 08:11:52 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A168B1AE34D for ; Mon, 16 Dec 2013 08:11:52 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C6343401EA for ; Mon, 16 Dec 2013 11:11:51 -0500 (EST) Message-ID: <52AF2647.8030308@viagenie.ca> Date: Mon, 16 Dec 2013 11:11:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] the new update is available: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:11:54 -0000 Le 2013-12-16 01:49, Lorenzo Colitti a écrit : > ICE is not only useful for NAT traversal, but also firewall > traversal for both IPv4 and IPv6. That is, ICE (or NAT-PMP, or UPnP > IGD, or PCP) is needed if the IPv6 network has simple security > (RFC6092). > > > Actually it isn't necessarily needed. > > If two parties establish a bidirectional stream (which in the case of a > voice or video call they will), then each endpoint's outgoing packets to > the other endpoint will punch a hole in its firewall that allows the > other endpoint's packets to come in, and you don't need ICE for anything. What you describe is ICE, is it not? 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 ayourtch@cisco.com Mon Dec 16 09:06:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF5F1AE078 for ; Mon, 16 Dec 2013 09:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdCtKXSjiA9B for ; Mon, 16 Dec 2013 09:06:00 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E5B111AE073 for ; Mon, 16 Dec 2013 09:05:59 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBGH5w8Z014300 for ; Mon, 16 Dec 2013 18:05:58 +0100 (CET) Received: from [10.61.167.202] ([10.61.167.202]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBGH5rgg003062; Mon, 16 Dec 2013 18:05:54 +0100 (CET) Date: Mon, 16 Dec 2013 17:05:50 +0000 (WET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Ted Lemon In-Reply-To: <411BFDB9-101D-4FC5-9A81-35140F8F5643@nominum.com> Message-ID: References: <411BFDB9-101D-4FC5-9A81-35140F8F5643@nominum.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2002645334-1387213554=:40639" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:06:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2002645334-1387213554=:40639 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 16 Dec 2013, Ted Lemon wrote: > On Dec 16, 2013, at 9:09 AM, Andrew Yourtchenko wrote: >> When/if we discover that everyone's in violent agreement, we add them back. What do you think ? > > Sure. I don't mean to pressure you to add or remove anything—I just > think it's worth mentioning substantive performance issues, of which > some exist. It's definitely not worth listing anything that is > controversial—I think there are some known performance issues that > everybody agrees exist, and I think those are arguably worth mentioning. > > > But if you think the document stands without them, that's fine with me too. > I think I made a mistake of adding too much at once, this was a good way to cut some of the more controversial parts, at least for now. It's easy to re-add later if we find a clear wording that has consensus. --a --0-2002645334-1387213554=:40639-- From fred@cisco.com Mon Dec 16 09:12:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1120D1AE1C8 for ; Mon, 16 Dec 2013 09:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.039 X-Spam-Level: X-Spam-Status: No, score=-110.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdmcny8TrYcz for ; Mon, 16 Dec 2013 09:12:38 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 85CC31AE069 for ; Mon, 16 Dec 2013 09:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2246; q=dns/txt; s=iport; t=1387213958; x=1388423558; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9J+ndAuMW9OXxJFk7Ge/RpH7oGjy2e+g/QFQ3J61UJY=; b=ZpNBYXF6+pTFr8JpTItjllL6IuHdtXvVHDH8WlLPiLvuZy0U4k0G9ugC ST27lw0cqNa34Fghczd0hFTcXu0uxf2zWSnV0x9QOkGkP4T0krkDXDE3+ xhGdwbuDMJmd2F0bg0efRgfTyDrzIXrMgppA9xTVJLLN3OVfiVjTtO2y+ M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAGwzr1KtJV2Z/2dsb2JhbABZgwqBDbhygSUWdIIlAQEBAwF5BQsCAQgYLjIlAgQOBQ6HbgjIIhePGQeDI4ETBJAzgTGGMpIUgyqCKg X-IronPort-AV: E=Sophos;i="4.95,496,1384300800"; d="asc'?scan'208";a="7125878" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 16 Dec 2013 17:12:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBGHCbmd005323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Dec 2013 17:12:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 16 Dec 2013 11:12:37 -0600 From: "Fred Baker (fred)" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt Thread-Index: AQHO+oID+iDcgTpmFkixltupjvLiPA== Date: Mon, 16 Dec 2013 17:12:36 +0000 Message-ID: <2E04735E-625B-479C-A579-181F7F18FBAB@cisco.com> References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> <7468AC73-6B83-41A3-B961-A815443CF6D6@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_A7BC58D3-6175-47C7-B52B-0F96A3C19167"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:12:40 -0000 --Apple-Mail=_A7BC58D3-6175-47C7-B52B-0F96A3C19167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 15, 2013, at 11:58 PM, Lorenzo Colitti = wrote: > On Mon, Dec 16, 2013 at 4:49 PM, Fred Baker (fred) = wrote: > True for normative references; this is informative, which the argument = doesn't hold for. >=20 > The statement in the draft is >=20 > Unique Local Addresses (ULAs) are defined in [RFC4193] to be > renumbered within a network site for local communications. = Operators > may use ULAs as NAT64 prefixes to provide site-local IPv6 > connectivity. Those ULA prefixes are stripped when the packets = going > to the IPv4 Internet, therefore ULAs are only valid in the IPv6 = site. > The use of ULAs could help in identifying the translation > traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided > further guidance for the ULAs usages. >=20 > what, specifically, is your objection? >=20 > I was referring to the text = "[I-D.ietf-v6ops-ula-usage-recommendations] has provided > further guidance for the ULAs usages.". That document is not an RFC = yet, and I thought that it was inappropriate to cite it from other RFCs. = If you're saying that's not an issue, then that's fine. >=20 > That said, I think the document shouldn't say "has provided further = guidance" because we don't yet know what guidance will be. If anything = it should say "provides further guidance". If your point is to make is say that it "may be of interest to the = reader" or such, so be it. My point was that the rule you cited was = inaccurately applied. --Apple-Mail=_A7BC58D3-6175-47C7-B52B-0F96A3C19167 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSrzSCbjEdbHIsm0MRAraBAKDBDC0zjOaf+FCKKMkd9oLPyzmdmgCgyziO ASKc8H7pwqHPajyZ3gXn6JQ= =PUMt -----END PGP SIGNATURE----- --Apple-Mail=_A7BC58D3-6175-47C7-B52B-0F96A3C19167-- From owen@delong.com Mon Dec 16 12:49:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1261AD942 for ; Mon, 16 Dec 2013 12:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euEHc4JmMs8G for ; Mon, 16 Dec 2013 12:49:39 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EE2D21AD939 for ; Mon, 16 Dec 2013 12:49:38 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBGKkHcP008385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Dec 2013 12:46:17 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBGKkHcP008385 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1387226777; bh=Hyu1XVOpsRaAGrXcX6micZEaDjw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=5VmO44nKNCN8N/kiEosjx6lPrwABwPGARTW7IImpcjyE7Q2KR/rL7JZ6Lcq47ukwi VfuU934m3oN85zQNF4w+0eVOh9LsH8o04S4Y8s2nNNFDFgMCYwH3DdVNuJsqJiptQ9 vYvogdD/2zuF8xqNjnO4H0YRdMVyFsj14TbLOiYU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <94433006-8AF6-45ED-B247-03EC1B397356@employees.org> Date: Mon, 16 Dec 2013 12:46:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94433006-8AF6-45ED-B247-03EC1B397356@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 16 Dec 2013 12:46:17 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 20:49:41 -0000 On Dec 16, 2013, at 06:25 , Ole Troan wrote: > Lorenzo, >=20 >>> Second: some of the text you have now deals with link-layer = performance. However, I think that since these are configuration = protocols, the attributes that are important are primarily semantics, = not performance or implementation. >>=20 >> Lorenzo, this is kind of a puzzling position to take. There are = lots of ways to do things with really nice semantics that fall on their = face for performance reasons. So I think performance questions are in = scope. >>=20 >> Oh, of course - in general, they are. But here the protocols used are = so similar that there is little substantive difference in performance. >=20 > could you expand on that? > I see the scaling properties on a multicast capable link very = different between the two. > take a multicast capable link with 10K nodes on it, where power has = just come back. > a few hundred RS/RA messages, at least 40K DHCPv6 messages. I'm trying to think of a multi-user network technology still in use = today where 40,000 packets over a couple of minutes time is likely to be = a significant load and I'm failing to come up with one. Care to elaborate? Owen From otroan@employees.org Mon Dec 16 13:46:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A5B1AC4AB for ; Mon, 16 Dec 2013 13:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTXYIlzAwaTI for ; Mon, 16 Dec 2013 13:46:18 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF11AD942 for ; Mon, 16 Dec 2013 13:46:17 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFZ0r1KQ/khM/2dsb2JhbABZgwq5V4EmFnSCJgEBBHkQC0ZXBogXsQaXMheOS04HgyOBEwSQM5l3gys7 X-IronPort-AV: E=Sophos;i="4.95,497,1384300800"; d="asc'?scan'208";a="2330402" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 16 Dec 2013 21:46:04 +0000 Received: from dhcp-10-61-105-70.cisco.com (dhcp-10-61-105-70.cisco.com [10.61.105.70]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBGLk3Yf005390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 21:46:04 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_6EA0D0E1-DA81-43D0-8F0A-9A5B1E434302"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Mon, 16 Dec 2013 22:46:03 +0100 Message-Id: <904EFC8A-7B13-4F1A-B538-A6605E635C3D@employees.org> References: <94433006-8AF6-45ED-B247-03EC1B397356@employees.org> To: Owen DeLong X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 21:46:19 -0000 --Apple-Mail=_6EA0D0E1-DA81-43D0-8F0A-9A5B1E434302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Owen, >>>> Second: some of the text you have now deals with link-layer = performance. However, I think that since these are configuration = protocols, the attributes that are important are primarily semantics, = not performance or implementation. >>>=20 >>> Lorenzo, this is kind of a puzzling position to take. There are = lots of ways to do things with really nice semantics that fall on their = face for performance reasons. So I think performance questions are in = scope. >>>=20 >>> Oh, of course - in general, they are. But here the protocols used = are so similar that there is little substantive difference in = performance. >>=20 >> could you expand on that? >> I see the scaling properties on a multicast capable link very = different between the two. >> take a multicast capable link with 10K nodes on it, where power has = just come back. >> a few hundred RS/RA messages, at least 40K DHCPv6 messages. >=20 > I'm trying to think of a multi-user network technology still in use = today where 40,000 packets over a couple of minutes time is likely to be = a significant load and I'm failing to come up with one. indeed, I wasn't thinking of link-congestion, but processing time. on = the DHCP server and the first-hop switches and routers. do you agree that RS/RA and DHCP scales quite differently in this = scenario? (then we can argue later if the differences matter or not). cheers, Ole --Apple-Mail=_6EA0D0E1-DA81-43D0-8F0A-9A5B1E434302 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSr3SbAAoJEFuJXizso86g92kH/3sbA1lKeQ9xNQNIGfvoKRiv YdC+tG5A/dQXY8qtS8XaoVU76Do1BY0i9uUq7Jr6Rb7DZQRgOCqzon9aoV1ak0nJ rVRewFoKRJivP9hfkX095bhNKl58Oe3o07BQF6XXcvSv2HmJMa0tMyEh6k9tDZSD 6RUKKLMJm6I0ItN51BOO6ksAsm+lmp5WAndto8rtjF9qfXqb3CW5z6eV7xko0iwo iv1LGqeAZBciB4qyElHja+mec3zrpiV60cGxPQbB14u5cF02cAO1bOgeLMQnguTX MiUa65rffHudLVddnsJfbbTT7Ez2ha1QY9ACrBAjnYhLxF0V/R70ZhPyIeYnzv4= =C825 -----END PGP SIGNATURE----- --Apple-Mail=_6EA0D0E1-DA81-43D0-8F0A-9A5B1E434302-- From owen@delong.com Mon Dec 16 15:47:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C081ADE87 for ; Mon, 16 Dec 2013 15:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkurMJi-Eay9 for ; Mon, 16 Dec 2013 15:47:42 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D83C1ADF7F for ; Mon, 16 Dec 2013 15:47:41 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBGNiwdc013816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Dec 2013 15:44:58 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBGNiwdc013816 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1387237498; bh=AW6EAf6skcbab2C3w0GvPRzA5MY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ESAzvS0I4MpY2DuKGx72EnhXtRliIz/03cVNZJf26SZdzeYagm/PMY6O8k5WIcu8B iSq4fBjJIQ8DzJOQLLt6XH1goJNZtHhg6MZ8SeU7ZPtgUbA19bGy3f1K8rSkvAwOkZ m90GC7G3cfArQ22ZTzfeucNzzHAYKDVRV5tCv0WA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <904EFC8A-7B13-4F1A-B538-A6605E635C3D@employees.org> Date: Mon, 16 Dec 2013 15:44:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94433006-8AF6-45ED-B247-03EC1B397356@employees.org> <904EFC8A-7B13-4F1A-B538-A6605E635C3D@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 16 Dec 2013 15:44:58 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 23:47:44 -0000 On Dec 16, 2013, at 13:46 , Ole Troan wrote: > Owen, >=20 >>>>> Second: some of the text you have now deals with link-layer = performance. However, I think that since these are configuration = protocols, the attributes that are important are primarily semantics, = not performance or implementation. >>>>=20 >>>> Lorenzo, this is kind of a puzzling position to take. There are = lots of ways to do things with really nice semantics that fall on their = face for performance reasons. So I think performance questions are in = scope. >>>>=20 >>>> Oh, of course - in general, they are. But here the protocols used = are so similar that there is little substantive difference in = performance. >>>=20 >>> could you expand on that? >>> I see the scaling properties on a multicast capable link very = different between the two. >>> take a multicast capable link with 10K nodes on it, where power has = just come back. >>> a few hundred RS/RA messages, at least 40K DHCPv6 messages. >>=20 >> I'm trying to think of a multi-user network technology still in use = today where 40,000 packets over a couple of minutes time is likely to be = a significant load and I'm failing to come up with one. >=20 > indeed, I wasn't thinking of link-congestion, but processing time. on = the DHCP server and the first-hop switches and routers. > do you agree that RS/RA and DHCP scales quite differently in this = scenario? Meh... I think most modern DHCP servers could actually take that kind of = load without too much problem. In any real world scenario, 10,000 hosts = that are all DHCP clients on the same segment isn't all that likely. = However, even if we forego that reality for a moment, they won't likely = be homogeneous which means that they will take different amounts of time = to get to where they want to make their DHCP requests. Can we agree that = the spread would be at least 45 seconds and more likely somewhere in the = neighborhood of 120 seconds from the time of the first host requesting = to the last? If so, then you're talking about 40,000 packets (10,000 requests) over = 45 seconds =3D <1,000 PPS. If your switch and/or DHCP server can't = handle 1,000 PPS from 10,000 nodes, I'm mystified as to how you expect = that network to work when the power hasn't failed recently. I think in terms of the switch, there are a number of problems that are = more impactful than DHCP that would prevent me from attempting to put = 10K nodes on a single network segment. So, yes, I suppose, technically, there is a valid argument that the = scaling properties of RA and DHCP are different. However, I think it's = kind of the networking equivalent of Zeno's paradox... At some point you = have to just accept that close enough is close enough and splitting the = hair any further is pointless. I think this goes beyond that point. > (then we can argue later if the differences matter or not). >=20 I guess I'll concede that there is a theoretical difference, but I = remain unconvinced of an actual difference. I'm pretty sure that the = theoretical difference doesn't really matter. To know whether the actual one did or not, I'd have to see an example = where it might. Owen From brian.e.carpenter@gmail.com Mon Dec 16 16:49:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C721ADF98 for ; Mon, 16 Dec 2013 16:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkeOtDG75ML7 for ; Mon, 16 Dec 2013 16:49:51 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0262D1ADBCB for ; Mon, 16 Dec 2013 16:49:50 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id ld10so3693750pab.25 for ; Mon, 16 Dec 2013 16:49:50 -0800 (PST) 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=ulnc1D0hVIx/qkzvIYIFhAK/HO8ls/t8eI5MiXjrUhE=; b=QO1JXsjDbogXeo8KOdhJvR0jS3gX1780zzQDgxHt4iOPfpc7iwO+W4KRYF5kigzxLd zF8cy7pVNhEqeqswEEZvlYK++zvZtm9FZ6Azz4YaKWgTB5inPI3znHBPfJkZVsNYRbq6 o0aFJqqWehPE3Lyjyj+kobreKgH+7DbVDjVA1ZRan6ouj4Y7khHDzcsLWx8X21DY+/jY tWknfAAeHPzY4dJGAU1iEFFNQB1o2eLeWiL3bVOlN2VLZWICNUK2mEAiWOvkUZ4OOLX0 2sHxsE8fVz0fnqU6w6lnjEumUiZY74AeU8NzBWf5T51VewThxu/PSbFUk9TFpwJFeCcu T2WQ== X-Received: by 10.66.7.68 with SMTP id h4mr23977321paa.0.1387241390208; Mon, 16 Dec 2013 16:49:50 -0800 (PST) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id qv8sm29431727pbc.31.2013.12.16.16.49.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 16:49:49 -0800 (PST) Message-ID: <52AF9FAB.7060702@gmail.com> Date: Tue, 17 Dec 2013 13:49:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Yourtchenko References: <20131127125213.17409.86382.idtracker@ietfa.amsl.com> In-Reply-To: <20131127125213.17409.86382.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-yourtchenko-ra-dhcpv6-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 00:49:55 -0000 Hi, (Still on v6ops, although 6man might be appropriate.) I think that there are some topics quite deep inside the draft that really belong nearer the beginning. After all, these are the issues that will guide future work: do we add feature X to RA, DHCPv6, or both?. In a logical order, these topics are: a) 4. Differences between different types of network operators b) 2.11. Scope of use / Applicability (e.g. 2.7. Involvement or not into routing) (e.g. to what extent do we want feature-equivalence and a shared data model?) c) 2.10. Separate vs. unified management There may be other general topics but those three stood out for me. Oh, and there's this: > 2.13. Security tools impact comparison > > From Brian Carpenter. For further discussion. Not quite sure what I had in mind there. What I wrote (in off-list mail) was "There's also the question of how the approaches relate to APAM tools and to security tools." I can see that there might be interaction with APAM. Maybe there needs to be interaction with address-based security settings? Regards Brian From lorenzo@google.com Mon Dec 16 17:05:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1176A1ADFD6 for ; Mon, 16 Dec 2013 17:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85HqUEWmt7C5 for ; Mon, 16 Dec 2013 17:05:09 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB6A1ADFDA for ; Mon, 16 Dec 2013 17:05:09 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id k19so5091215igc.1 for ; Mon, 16 Dec 2013 17:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G+JIWPQ/o0Y7WHcysyoMsApd3rrBWf9hZVPQ5gaKqo0=; b=EIdHC6BiGpj2Ern1YzGsa53pdqM2kZOIg5YBllH9b0jsZ3XIeJUiiCNLX5z0Uug5D3 yGNaWALQe+FDSPD0j9yS+nTGxvWKv+dAz3yiv2zNh+aXt0PiLVnrgliysmrEc1yIQDh9 I5UcDUmfQazUfDXIIsRMNBHNUK2ZPPiqDINpgdRRIywb1BelLBvJL9KYUFB+DTwERE1h Y7trQjuSteFRV85lW/0gCwV1rNyqgq/JRHhMG/SAtgBKUeAJAwF8NrECxqsSCC51YnAw 93igOn0aQr+6+k/Pf2mjKPvlEdO0QwdkrBXSozEZZiATHnszQgfzSOLROKMxGqj/dJ4c XpOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=G+JIWPQ/o0Y7WHcysyoMsApd3rrBWf9hZVPQ5gaKqo0=; b=CWVNfouzLsJytcqgv8dMxmSLvDy09vGpn6rozzSDleeJSKh36Z8pXvZScFj4URZl46 QeL5DkYcYGsQCzuZU1OhwF27IeR4klEaStvLNzhinGb0KfUBCAHueT98g5usjX4vSgBo TMD5zIo7ICko+PIiffjJkWB+7eVyrr7wXMxKTvXKATYiqbtWFXoAarlz0B5lxuT4tsyG gF1e42P4/rOPd8nG323nhvxQxXa4PwlUWSq2tq8OExSNOo4jBlu3N4Hp6pZIPns/jZYR CAHlCRvMWuKgbTtkK1qVl1XxrJck4LpPX7i8YG6g6RqMjxmRsjV4Ky9Ed+eD4ZF+3tm/ wMeg== X-Gm-Message-State: ALoCoQlL8B9AfNyq8WRCmd5st+zmJ10mS4d/GiH5swnyO/4K5qS93aqW8BQfJKRp52uX3kJwI9yygVPA8kmOUqkSC3W9fyZnCMdiVvGdQm39ignXZS/KNSAK4IIHVZgu5/q3EYln7yyqiXAa7K/H3ZXiJDT7u64EcB7Q3dBQZhk2ZAQIeuJoDlOvHZk7YxMSCHDhVnz14UWj X-Received: by 10.42.214.202 with SMTP id hb10mr3047981icb.76.1387242308514; Mon, 16 Dec 2013 17:05:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Mon, 16 Dec 2013 17:04:48 -0800 (PST) In-Reply-To: <94433006-8AF6-45ED-B247-03EC1B397356@employees.org> References: <94433006-8AF6-45ED-B247-03EC1B397356@employees.org> From: Lorenzo Colitti Date: Tue, 17 Dec 2013 10:04:48 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=20cf301cc3b20459f104edb085d9 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Thoughts on draft-yourtchenko-ra-dhcpv6-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 01:05:11 -0000 --20cf301cc3b20459f104edb085d9 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 16, 2013 at 11:25 PM, Ole Troan wrote: > I see the scaling properties on a multicast capable link very different > between the two. > take a multicast capable link with 10K nodes on it, where power has just > come back. > a few hundred RS/RA messages, at least 40K DHCPv6 messages. > True. On the other hand, on wifi, multicast is expensive, both in terms of shared channel bandwidth and in terms of impact on device battery life if solicited RAs are sent to all-nodes multicast. Of course, you can avoid this by sending solicited RAs unicast. In the grand scheme of things I think these link-layer concerns are not the most important factors here. That said, if they're not controversial, then perhaps it's good to document them. --20cf301cc3b20459f104edb085d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 16, 2013 at 11:25 PM, Ole Troan <otroan@employees.org> wrote:
I see the scaling properties on a multicast = capable link very different between the two.
take a multicast capable link with 10K nodes on it, where power has just co= me back.
a few hundred RS/RA messages, at least 40K DHCPv6 messages.

True. On the other hand, on wifi, multicast is expensi= ve, both in terms of shared channel bandwidth and in terms of impact on dev= ice battery life if solicited RAs are sent to all-nodes multicast. Of cours= e, you can avoid this by sending solicited RAs unicast.

In the grand scheme of things I think these link-layer = concerns are not the most important factors here. That said, if they're= not controversial, then perhaps it's good to document them.
--20cf301cc3b20459f104edb085d9-- From leo.liubing@huawei.com Mon Dec 16 19:03:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9148D1AE055 for ; Mon, 16 Dec 2013 19:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIKbnAgIbrAT for ; Mon, 16 Dec 2013 19:03:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DB9A91ADFAC for ; Mon, 16 Dec 2013 19:03:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZB81708; Tue, 17 Dec 2013 03:03:43 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 03:03:17 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 03:03:41 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 11:03:37 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti , "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO8PcjWuMJf8I9f0eBAQAUd5rlEZpWADIAgAGs+wA= Date: Tue, 17 Dec 2013 03:03:36 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 03:03:48 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lorenzo, Thanks for the comments. Please see inline. From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Monday, December 16, 2013 3:55 PM To: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org Cc: v6ops@ietf.org WG Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem A few comments: 1. The draft should note that per RFC 6434 (IPv6 node requirements), hosts = MUST support SLAAC, but are not required to support DHCPv6, since it's a SH= OULD (and note that until relatively recently - December 2011 - it was a MA= Y). So while a network administrator can reasonably assume that SLAAC will = be supported by hosts, he cannot assume that DHCPv6 will be supported. [Bing] Good suggestion. Thank you. 2. The statement in Section 2.1.1 that "when A flag is set, the SLAAC proto= col didn't provide a prescriptive definition" is incorrect. RFC 4862 says that if A=3D0 the host should "silently ignore the Prefix Inf= ormation option", and if A=3D1 "form an address" (bullet point d) or "the p= referred lifetime of the address is reset [...]" (bullet point e). Both rul= es MUST be enabled by default, as clearly stated in RFC 4862 section 5.5. [Bing] The texts in section 2.1.1 means there is no explicit definition of = A=3D1. But there might be implication as you mentioned above. And the tests= in our draft also identified there's no problem of A=3D1. I'll revise the = texts accordingly to eliminate the confusion. 3. In section 3.3 it's not clear why "the administrator wants the hosts to = do DHCPv6-only configuration". All hosts that support DHCPv6 will do DHCPv6= -only if A=3D0 and M=3D1. Hosts that don't support DHCPv6... won't be able = to do DHCPv6-only regardless of what the administrator wants them to do. [Bing] It is true when there's RAs in the link. In section 5.5.2 of [RFC486= 2], it mentioned the situation of non-RAs. But non-RA only means "no router= " as described in the standard, it is not clear whether the hosts should in= itiate DHCPv6 or not. And as we tested, some hosts just do nothing if no R= As present. So there's an implication that it requires RA to indicate the hosts to do D= HCPv6 (unless the hosts are switched to DHCPv6-only mode manually or throug= h some management tools, but this might involve management burden and non-s= tandard mechanisms). And this is just one of the issues we'd like to point = out in this draft. Best Regards, Bing On Wed, Dec 4, 2013 at 10:45 PM, > wr= ote: A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops= -dhcpv6-slaac-problem. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lorenzo= ,

 = ;

Thanks for= the comments. Please see inline.

 = ;

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Monday, December 16, 2013 3:55 PM
To: draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-proble= m

 

A few comments:

 

1. The draft should note that p= er RFC 6434 (IPv6 node requirements), hosts MUST support SLAAC, but are not= required to support DHCPv6, since it's a SHOULD (and note that until relat= ively recently - December 2011 - it was a MAY). So while a network administrator can reasonably assume that SL= AAC will be supported by hosts, he cannot assume that DHCPv6 will be suppor= ted.

[Bing] = Good suggestion. Thank you.

 = ;

2. The statement in Section 2.1= .1 that "when A flag is set, the SLAAC protocol didn't provide a presc= riptive definition" is incorrect.

 

RFC 4862 says that if A=3D0 the= host should "silently ignore the Prefix Information option", and= if A=3D1 "form an address" (bullet point d) or "the preferr= ed lifetime of the address is reset [...]" (bullet point e). Both rules MUST be enabled by default, as clearly stated in RFC 4862 section 5.= 5.

[Bing] = The texts in section 2.1.1 means there is no explicit definition of A=3D1. = But there might be implication as you mentioned above. And the tests in our= draft also identified there’s no problem of A=3D1. I’ll revise the texts accordingly to eliminate the confusi= on.

 

3. In section 3.3 it's not clea= r why "the administrator wants the hosts to do DHCPv6-only configurati= on". All hosts that support DHCPv6 will do DHCPv6-only if A=3D0 and M= =3D1. Hosts that don't support DHCPv6... won't be able to do DHCPv6-only regardless of what the administrator wants them to do.

[Bing] It = is true when there’s RAs in the link. In section 5.5.2 of [RFC4862], = it mentioned the situation of non-RAs. But non-RA only means “no router” as described in the standard, it is not clear whether the ho= sts should initiate DHCPv6 or not. And as we tested,  some hosts just = do nothing if no RAs present.

So there&#= 8217;s an implication that it requires RA to indicate the hosts to do DHCPv= 6 (unless the hosts are switched to DHCPv6-only mode manually or through some management tools, but this might involve management burden an= d non-standard mechanisms). And this is just one of the issues we’d l= ike to point out in this draft.

 = ;

Best Regar= ds,

Bing<= /o:p>

 = ;

=  

On Wed, Dec 4, 2013 at 10:45 PM= , <fred@cisco.com> wrote:


A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Pleas= e take a look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0nkgeml506mbxchi_-- From lorenzo@google.com Mon Dec 16 19:11:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A16D1ADFDF for ; Mon, 16 Dec 2013 19:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB6yR63yXzaH for ; Mon, 16 Dec 2013 19:11:49 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D779B1AE064 for ; Mon, 16 Dec 2013 19:11:48 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id qd12so7730609ieb.15 for ; Mon, 16 Dec 2013 19:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LYb/3dJaGU3nle217GtJaABP51JRJcs5bCO06WcS1+4=; b=Xs532RxlSSwO+CRvx4ZJ+WWsBgk4Z/1sN1B+J9WDxzEUukIEN2c/xY0MBYu9v73dbs wUVcbkwves0FAQ3AslR8m+Y0j4Cap38BSdtakKmmCwTzuPmYtyA8zPlmvPTIdr3l2Ks+ 21QKs9+LO6/SHqRHcO5D9C7YSW4mdEsTi3Uk5YM5jUwZfZrgb8/0Xw0NlN/4LZwO+4g8 lvuUzNbDvOwGuPDqwEb4Q/XZtJfsB89gYj2PgrKsKmVjPzkU3hTaH5k/hKrleTwF6VCw MC/VJPP3UGkqapfzDWKmtibwV8rlZ6WPuZk/S4uHtQh8LFBj7D0MLZWV/ZLajHmbq7hO FYPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LYb/3dJaGU3nle217GtJaABP51JRJcs5bCO06WcS1+4=; b=afaK5KUIW/r3lCzn0mYjP52CcnV3n413xWbMzFENqrqIXdAJ2zX+abhPxEKvuayOb2 T9pH+8xPjjaZSCiKBfkRYdlntr+KDBQE1RvdwF40nhkiEodoDwSvDTdmggmcsF0Lx5gR a10YoaO7NzNIDSi4rEWKydoYNc7BvaR4zkq82My5z8OaT4ZZkOAwFeWOvbrQWJLHWoFk sMISRP7qboLbjgMRuAObUeXM6PztrEk9FYCRJy/rM49xqbu/iZKZmXywe9E0qEiTzod/ mNfAPxjNyQzDRGWClxEQP/2vZpR5N7LuI5WBrW159r/vszLa+A4S5CYL+0EL7eym3Bfx 0KKw== X-Gm-Message-State: ALoCoQmUNxYlOF1KpnRhP0qE1+xzmcnTf2f3B0JfNDidaXH8D0PKoTibSHzCbEbZGl4n/W0nTypW2HvGl+5vW/THG1aHEBisjBUKwrQ+3U2LC5xUNQGCXRp7uguMhqdpD4/BMrWu1LvD/blB50fYWwzF/h+lzo3Kmk3FV5M0wQFvhg3rpvItwR+xw8oCQtA123BMaRxDAnSB X-Received: by 10.43.178.135 with SMTP id ow7mr14778391icc.43.1387249907690; Mon, 16 Dec 2013 19:11:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Mon, 16 Dec 2013 19:11:27 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 17 Dec 2013 12:11:27 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c30becf68e1a04edb2497d Cc: "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 03:11:50 -0000 --001a11c30becf68e1a04edb2497d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 17, 2013 at 12:03 PM, Liubing (Leo) wro= te: > 3. In section 3.3 it's not clear why "the administrator wants the hosts > to do DHCPv6-only configuration". All hosts that support DHCPv6 will do > DHCPv6-only if A=3D0 and M=3D1. Hosts that don't support DHCPv6... won't = be > able to do DHCPv6-only regardless of what the administrator wants them to > do. > > [Bing] It is true when there=E2=80=99s RAs in the link. In section 5.5.2 = of > [RFC4862], it mentioned the situation of non-RAs. But non-RA only means = =E2=80=9Cno > router=E2=80=9D as described in the standard, it is not clear whether the= hosts > should initiate DHCPv6 or not. And as we tested, some hosts just do > nothing if no RAs present. > > So there=E2=80=99s an implication that it requires RA to indicate the hos= ts to do > DHCPv6 (unless the hosts are switched to DHCPv6-only mode manually or > through some management tools, but this might involve management burden a= nd > non-standard mechanisms). And this is just one of the issues we=E2=80=99d= like to > point out in this draft. > But why would you do this? If there's no RA, then the hosts won't be able to communicate off-link. If all you can do is link-local communication, then what's the point of numbering the hosts via DHCPv6 instead of just using link-local? --001a11c30becf68e1a04edb2497d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 17, 2013 at 12:03 PM, Liubing (Leo) <leo.liubing@huawei.com= > wrote:

3. In section 3.3 it's not clear why "the administrator wants = the hosts to do DHCPv6-only configuration". All hosts that support DHC= Pv6 will do DHCPv6-only if A=3D0 and M=3D1. Hosts that don't support DH= CPv6... won't be able to do DHCPv6-only regardless of what the administrator wants them to do.

[Bin= g] It is true when there=E2=80=99s RAs in the link. In section 5.5.2 of [RF= C4862], it mentioned the situation of non-RAs. But non-RA only means =E2=80= =9Cno router=E2=80=9D as described in the standard, it is not clear whether the = hosts should initiate DHCPv6 or not. And as we tested, =C2=A0some hosts jus= t do nothing if no RAs present.

So there= =E2=80=99s an implication that it requires RA to indicate the hosts to do D= HCPv6 (unless the hosts are switched to DHCPv6-only mode manually or through some management tools, but this might involve management burden an= d non-standard mechanisms). And this is just one of the issues we=E2=80=99d= like to point out in this draft.

<= /blockquote>

But why would you do this? If there's no RA, then t= he hosts won't be able to communicate off-link. If all you can do is li= nk-local communication, then what's the point of numbering the hosts vi= a DHCPv6 instead of just using link-local?
--001a11c30becf68e1a04edb2497d-- From leo.liubing@huawei.com Mon Dec 16 19:47:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4231AE098 for ; Mon, 16 Dec 2013 19:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQVIEP0U8_cb for ; Mon, 16 Dec 2013 19:47:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A87601AE091 for ; Mon, 16 Dec 2013 19:47:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBM75343; Tue, 17 Dec 2013 03:47:11 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 03:46:43 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 03:47:09 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 11:47:03 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO8PcjWuMJf8I9f0eBAQAUd5rlEZpWADIAgAGs+wD//5YhgIAAht9g Date: Tue, 17 Dec 2013 03:47:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 03:47:18 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMTcsIDIwMTMgMTE6MTEgQU0NClRvOiBMaXViaW5nIChMZW8pDQpD YzogZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbUB0b29scy5pZXRmLm9yZzsg djZvcHNAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQt aWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbQ0KDQpPbiBUdWUsIERlYyAxNywgMjAxMyBh dCAxMjowMyBQTSwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2VpLmNvbTxtYWlsdG86 bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KMy4gSW4gc2VjdGlvbiAzLjMgaXQncyBu b3QgY2xlYXIgd2h5ICJ0aGUgYWRtaW5pc3RyYXRvciB3YW50cyB0aGUgaG9zdHMgdG8gZG8gREhD UHY2LW9ubHkgY29uZmlndXJhdGlvbiIuIEFsbCBob3N0cyB0aGF0IHN1cHBvcnQgREhDUHY2IHdp bGwgZG8gREhDUHY2LW9ubHkgaWYgQT0wIGFuZCBNPTEuIEhvc3RzIHRoYXQgZG9uJ3Qgc3VwcG9y dCBESENQdjYuLi4gd29uJ3QgYmUgYWJsZSB0byBkbyBESENQdjYtb25seSByZWdhcmRsZXNzIG9m IHdoYXQgdGhlIGFkbWluaXN0cmF0b3Igd2FudHMgdGhlbSB0byBkby4NCltCaW5nXSBJdCBpcyB0 cnVlIHdoZW4gdGhlcmXigJlzIFJBcyBpbiB0aGUgbGluay4gSW4gc2VjdGlvbiA1LjUuMiBvZiBb UkZDNDg2Ml0sIGl0IG1lbnRpb25lZCB0aGUgc2l0dWF0aW9uIG9mIG5vbi1SQXMuIEJ1dCBub24t UkEgb25seSBtZWFucyDigJxubyByb3V0ZXLigJ0gYXMgZGVzY3JpYmVkIGluIHRoZSBzdGFuZGFy ZCwgaXQgaXMgbm90IGNsZWFyIHdoZXRoZXIgdGhlIGhvc3RzIHNob3VsZCBpbml0aWF0ZSBESENQ djYgb3Igbm90LiBBbmQgYXMgd2UgdGVzdGVkLCAgc29tZSBob3N0cyBqdXN0IGRvIG5vdGhpbmcg aWYgbm8gUkFzIHByZXNlbnQuDQpTbyB0aGVyZeKAmXMgYW4gaW1wbGljYXRpb24gdGhhdCBpdCBy ZXF1aXJlcyBSQSB0byBpbmRpY2F0ZSB0aGUgaG9zdHMgdG8gZG8gREhDUHY2ICh1bmxlc3MgdGhl IGhvc3RzIGFyZSBzd2l0Y2hlZCB0byBESENQdjYtb25seSBtb2RlIG1hbnVhbGx5IG9yIHRocm91 Z2ggc29tZSBtYW5hZ2VtZW50IHRvb2xzLCBidXQgdGhpcyBtaWdodCBpbnZvbHZlIG1hbmFnZW1l bnQgYnVyZGVuIGFuZCBub24tc3RhbmRhcmQgbWVjaGFuaXNtcykuIEFuZCB0aGlzIGlzIGp1c3Qg b25lIG9mIHRoZSBpc3N1ZXMgd2XigJlkIGxpa2UgdG8gcG9pbnQgb3V0IGluIHRoaXMgZHJhZnQu DQoNCkJ1dCB3aHkgd291bGQgeW91IGRvIHRoaXM/IElmIHRoZXJlJ3Mgbm8gUkEsIHRoZW4gdGhl IGhvc3RzIHdvbid0IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgb2ZmLWxpbmsuIElmIGFsbCB5b3Ug Y2FuIGRvIGlzIGxpbmstbG9jYWwgY29tbXVuaWNhdGlvbiwgdGhlbiB3aGF0J3MgdGhlIHBvaW50 IG9mIG51bWJlcmluZyB0aGUgaG9zdHMgdmlhIERIQ1B2NiBpbnN0ZWFkIG9mIGp1c3QgdXNpbmcg bGluay1sb2NhbD8NCltCaW5nXSBXaXRoIGRyYWZ0LWlldGYtbWlmLWRoY3B2Ni1yb3V0ZS1vcHRp b24sIHRoZSBob3N0cyB3b3VsZCBiZSBhYmxlIHRvIGNvbW11bmljYXRlIG9mZi1saW5rIHdpdGhv dXQgUkEuIEkgdGhpbmsgdGhpcyBzY2VuYXJpbyBpcyBxdWl0ZSByZWFzb25hYmxlIGVzcGVjaWFs bHkgZm9yIHRoZSBvcGVyYXRvcnMuDQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkg W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RGVjZW1iZXIgMTcsIDIwMTMgMTE6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+IExpdWJpbmcgKExlbyk8 YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW1AdG9v bHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb djZvcHNdIG5ldyBkcmFmdDogZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IFR1ZSwgRGVjIDE3LCAyMDEzIGF0IDEyOjAzIFBNLCBMaXViaW5nIChMZW8pICZsdDs8YSBocmVm PSJtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxlby5saXVi aW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4zLiBJbiBzZWN0aW9uIDMu MyBpdCdzIG5vdCBjbGVhciB3aHkgJnF1b3Q7dGhlIGFkbWluaXN0cmF0b3Igd2FudHMgdGhlIGhv c3RzIHRvIGRvIERIQ1B2Ni1vbmx5IGNvbmZpZ3VyYXRpb24mcXVvdDsuIEFsbCBob3N0cyB0aGF0 IHN1cHBvcnQgREhDUHY2IHdpbGwgZG8gREhDUHY2LW9ubHkgaWYNCiBBPTAgYW5kIE09MS4gSG9z dHMgdGhhdCBkb24ndCBzdXBwb3J0IERIQ1B2Ni4uLiB3b24ndCBiZSBhYmxlIHRvIGRvIERIQ1B2 Ni1vbmx5IHJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGUgYWRtaW5pc3RyYXRvciB3YW50cyB0aGVtIHRv IGRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltCaW5nXSBJdCBpcyB0cnVlIHdoZW4gdGhlcmXigJlzIFJBcyBpbiB0aGUgbGluay4gSW4gc2Vj dGlvbiA1LjUuMiBvZiBbUkZDNDg2Ml0sIGl0IG1lbnRpb25lZA0KIHRoZSBzaXR1YXRpb24gb2Yg bm9uLVJBcy4gQnV0IG5vbi1SQSBvbmx5IG1lYW5zIOKAnG5vIHJvdXRlcuKAnSBhcyBkZXNjcmli ZWQgaW4gdGhlIHN0YW5kYXJkLCBpdCBpcyBub3QgY2xlYXIgd2hldGhlciB0aGUgaG9zdHMgc2hv dWxkIGluaXRpYXRlIERIQ1B2NiBvciBub3QuIEFuZCBhcyB3ZSB0ZXN0ZWQsICZuYnNwO3NvbWUg aG9zdHMganVzdCBkbyBub3RoaW5nIGlmIG5vIFJBcyBwcmVzZW50Lg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ U28gdGhlcmXigJlzIGFuIGltcGxpY2F0aW9uIHRoYXQgaXQgcmVxdWlyZXMgUkEgdG8gaW5kaWNh dGUgdGhlIGhvc3RzIHRvIGRvIERIQ1B2NiAodW5sZXNzDQogdGhlIGhvc3RzIGFyZSBzd2l0Y2hl ZCB0byBESENQdjYtb25seSBtb2RlIG1hbnVhbGx5IG9yIHRocm91Z2ggc29tZSBtYW5hZ2VtZW50 IHRvb2xzLCBidXQgdGhpcyBtaWdodCBpbnZvbHZlIG1hbmFnZW1lbnQgYnVyZGVuIGFuZCBub24t c3RhbmRhcmQgbWVjaGFuaXNtcykuIEFuZCB0aGlzIGlzIGp1c3Qgb25lIG9mIHRoZSBpc3N1ZXMg d2XigJlkIGxpa2UgdG8gcG9pbnQgb3V0IGluIHRoaXMgZHJhZnQuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IHdoeSB3b3VsZCB5b3UgZG8gdGhp cz8gSWYgdGhlcmUncyBubyBSQSwgdGhlbiB0aGUgaG9zdHMgd29uJ3QgYmUgYWJsZSB0byBjb21t dW5pY2F0ZSBvZmYtbGluay4gSWYgYWxsIHlvdSBjYW4gZG8gaXMgbGluay1sb2NhbCBjb21tdW5p Y2F0aW9uLCB0aGVuIHdoYXQncyB0aGUgcG9pbnQgb2YgbnVtYmVyaW5nIHRoZSBob3N0cyB2aWEg REhDUHY2IGluc3RlYWQgb2YganVzdA0KIHVzaW5nIGxpbmstbG9jYWw/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gV2l0aCBkcmFmdC1pZXRmLW1pZi1k aGNwdjYtcm91dGUtb3B0aW9uLCB0aGUgaG9zdHMgd291bGQgYmUgYWJsZSB0byBjb21tdW5pY2F0 ZSBvZmYtbGluayB3aXRob3V0IFJBLiBJIHRoaW5rIHRoaXMgc2NlbmFyaW8gaXMgcXVpdGUgcmVh c29uYWJsZQ0KIGVzcGVjaWFsbHkgZm9yIHRoZSBvcGVyYXRvcnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1nkgeml506mbxchi_-- From lorenzo@google.com Mon Dec 16 19:52:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95611AE08F for ; Mon, 16 Dec 2013 19:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFtBgsC0VUaK for ; Mon, 16 Dec 2013 19:52:30 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 349561AE0A6 for ; Mon, 16 Dec 2013 19:52:30 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id k19so5356295igc.1 for ; Mon, 16 Dec 2013 19:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iI60Q0ihzuvS2EanaRyGX1AH+zqaCqWthLO4xdEVmBc=; b=h3xEQ6qi8oPuPAVLd8Lxm6YVlHkAyobtNA9trxFDbfH0QjSoLaObGFAdw2WL17IBFX Bcb/0fIHJ5TDFWRL1urdNfj1TeLssH4VDJrlFp3eOzLWwiv20uegYjfkVbjNGSryk0ga seaEx/5UZIFp73yOnKI3yLmgXLkrjWM7c7wFA8XnVq3YcNnMsETY/Mug5wte646bEDIy X3mpL/7YPVq2KU7nF9hu+ocO6bAnroWV3H0YTj4+NPgfZP3SxadSe3VyCajzCowQOIkQ NnAlLq5SEfhS0Zl32sefIoeuCLts3IO+L0kyfUzxHcx846nh+ehgrlkx2dYYw2/WtLnZ glag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iI60Q0ihzuvS2EanaRyGX1AH+zqaCqWthLO4xdEVmBc=; b=Zc+beyOPmR3lnVxXcbp9BsWJPpDNJoCm4tuqN+YeKdh9dBB8jL1O7oCoTOpr7brDov 9xYTsBV3flG9x6MLNhCpUYfNxz+EzOwhN90tVGwdb2fuM1/YALNmYl5M9R/eFDx02Aj6 MV0P1QFyPVhPGvzi564Y9K/nX/fEgqqaVo0gR4d9rq0p6Cz2898HmW7bm2vRIKZAnCUA siXFruE8ZamHc9Ir7s9ik4VNspXo52D6xzC4JLJwq53YuV9iNFqhUwdSk/Y1XrSlq+xN V+lxukrHmRg3FpHKeo7d+jXk0w0Jv54MTLZc0St4TrFft5VlA9uvi5jhn0mSfibIh5T+ phzA== X-Gm-Message-State: ALoCoQlEMFZ+m7hZQjzWmefqcyITuQ18tzJkbA7HVi3j1kA0G6geDUxO6aguWW95iFJNsgTlGvnIEQOn4jnzT89Yu6xX5K0GP/jivUcJTltJY/A2SiSMWtNHsnWW7442Yi2AonrIkzuji85XmM8phBbaVfQfl6SKw8tt4/MI7nnrMKvRgXkmX4TQI1Altbcq3I2gBn9xFbVn X-Received: by 10.43.16.2 with SMTP id pw2mr4118079icb.56.1387252349241; Mon, 16 Dec 2013 19:52:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Mon, 16 Dec 2013 19:52:09 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 17 Dec 2013 12:52:09 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=bcaec5101bfb7db95c04edb2db0f Cc: "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 03:52:35 -0000 --bcaec5101bfb7db95c04edb2db0f Content-Type: text/plain; charset=UTF-8 On Tue, Dec 17, 2013 at 12:47 PM, Liubing (Leo) wrote: > But why would you do this? If there's no RA, then the hosts won't be > able to communicate off-link. If all you can do is link-local > communication, then what's the point of numbering the hosts via DHCPv6 > instead of just using link-local? > > [Bing] With draft-ietf-mif-dhcpv6-route-option, the hosts would be able to > communicate off-link without RA. I think this scenario is quite reasonable > especially for the operators. > But that draft did not reach consensus and is no longer an active working group item, so it's unlikely to happen any time soon. If this use case only makes sense if routing is configured with DHCPv6, then the use case should be removed. --bcaec5101bfb7db95c04edb2db0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 17, 2013 at 12:47 PM, Liubing (Leo) <leo.liubing@huawei.com= > wrote:

But why would you= do this? If there's no RA, then the hosts won't be able to communi= cate off-link. If all you can do is link-local communication, then what'= ;s the point of numbering the hosts via DHCPv6 instead of just using link-local?

[Bing] With draft-= ietf-mif-dhcpv6-route-option, the hosts would be able to communicate off-li= nk without RA. I think this scenario is quite reasonable especially for the operators.


But that draft did = not reach consensus and is no longer an active working group item, so it= 9;s unlikely to happen any time soon. If this use case only makes sense if = routing is configured with DHCPv6, then the use case should be removed.
--bcaec5101bfb7db95c04edb2db0f-- From Ted.Lemon@nominum.com Mon Dec 16 20:05:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196B71AE07C for ; Mon, 16 Dec 2013 20:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plCr-dcxq6VO for ; Mon, 16 Dec 2013 20:05:10 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6E87A1AE05C for ; Mon, 16 Dec 2013 20:05:10 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUq/NdS+agKcRKSsafiOAnYtdOZozWjo3@postini.com; Mon, 16 Dec 2013 20:05:09 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7F3031B82C6 for ; Mon, 16 Dec 2013 20:05:09 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5758C190043; Mon, 16 Dec 2013 20:05:09 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Dec 2013 20:05:03 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Mon, 16 Dec 2013 23:04:59 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 04:05:12 -0000 On Dec 16, 2013, at 10:52 PM, Lorenzo Colitti = wrote: > But that draft did not reach consensus and is no longer an active = working group item, so it's unlikely to happen any time soon. If this = use case only makes sense if routing is configured with DHCPv6, then the = use case should be removed. I think the use case makes sense in an isolated network. RA might be a = better choice, and indeed without RA I think it probably doesn't work, = but I don't see why this document shouldn't mention this use case. The = reason you've given here certainly doesn't seem convincing. From lorenzo@google.com Mon Dec 16 20:08:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF691AE0A6 for ; Mon, 16 Dec 2013 20:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lryk4uhDDx-h for ; Mon, 16 Dec 2013 20:08:56 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id AA5491AE098 for ; Mon, 16 Dec 2013 20:08:56 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so7727511ieb.22 for ; Mon, 16 Dec 2013 20:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RaCjfNrhDkWJM2I7kmRQzOOTl/GVewaEEvuCOLZg/Rc=; b=I3Vu2s6MNFrLghy2CzBW0lujCn/MQUIdSeXpaivRq5aeNP33BnWVH9qSNdwhQayKzi n2CCIUbRyvXHq4ZslkjqhiEYYSMGvytRRnDphzq0NMWBvtTwxW3hFgikwCj0/ayDZ7hp KpK9GX9oZwb0VBWiRMsXYUPsgBvqyNf50AH3LMgwTaTQknMWK6Adb5Bu6QZ+JI7MbsA7 IaWD7q1fKUPLKxamEbiJBCguP4+8TTCXGWVEYIRJk3uIdXIoXXVmJic1YgzMzlOwWbCa V/zJVEwHQxL0Q7XIcXRjnHovwRJucW1xCUSK+XqoFMUcaQ0TUzyL+Wx4yqeEKGuuj/h8 ELtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RaCjfNrhDkWJM2I7kmRQzOOTl/GVewaEEvuCOLZg/Rc=; b=QHgVUz1As4sPpYQTs2Jlax8VvStnB7qqfrtLhHgptzu1nYOwG9GhrFg4PfznC360zP Wz9NFCR1+RShxS8gk7ZcUcFYHGTgjBkldd+U+WWayeW4i9haIkfe3RMHES33/wGoVKFX FwF+D1axgSWEi/KGxMCnjKaO9xzUaZKuwYiAEiN26GvopNtcuuzAvVXpf5lwYxloTCv8 Gwb3QrEzKJMAz4t5LtEDtA+xriCbVYimc3X3+nTmb3hJxw35Idb7TS941TdhZz2mvs5B X1qC++XkTXSWM9oQxY9q8r9d2ZxmqPwCUflGNXgCskjQjKTfPPnDE6RaHsKWmfkA+33A fFMQ== X-Gm-Message-State: ALoCoQng3TK7tTPzeb5KatD96AyFsWNNznLPu83dv8lv09VkHYnd4CYWPLAanp6CZjBMAn53CRk0DtjQycxVShLi7APf/S3Q/UqB7ww0jvCYr8hFQ1lf8lDeK20ICGUZsuQd8NqSJ3snVQcPFoZncLhA3cO10OMvKGtrfSWvMkudn53/W37m85jjKfRVtGAi9EyRDQzhts10 X-Received: by 10.50.79.228 with SMTP id m4mr1118214igx.47.1387253335708; Mon, 16 Dec 2013 20:08:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Mon, 16 Dec 2013 20:08:34 -0800 (PST) In-Reply-To: <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> From: Lorenzo Colitti Date: Tue, 17 Dec 2013 13:08:34 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e013a1f1649f09404edb3166c Cc: "draft-ietf-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 04:08:58 -0000 --089e013a1f1649f09404edb3166c Content-Type: text/plain; charset=UTF-8 On Tue, Dec 17, 2013 at 1:04 PM, Ted Lemon wrote: > > But that draft did not reach consensus and is no longer an active > working group item, so it's unlikely to happen any time soon. If this use > case only makes sense if routing is configured with DHCPv6, then the use > case should be removed. > > I think the use case makes sense in an isolated network. RA might be a > better choice, and indeed without RA I think it probably doesn't work, but > I don't see why this document shouldn't mention this use case. The reason > you've given here certainly doesn't seem convincing. > If a DHCPv6-only scenario is presented, then it needs to be stated that the nodes will not have any off-link connectivity, and thus that this scenario is possibly of limited use. --089e013a1f1649f09404edb3166c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 17, 2013 at 1:04 PM, Ted Lemon <ted.lemon@nominum.com><= /span> wrote:
> But that draft did no= t reach consensus and is no longer an active working group item, so it'= s unlikely to happen any time soon. If this use case only makes sense if ro= uting is configured with DHCPv6, then the use case should be removed.

I think the use case makes sense in an isolated network. =C2=A0 RA mi= ght be a better choice, and indeed without RA I think it probably doesn'= ;t work, but I don't see why this document shouldn't mention this u= se case. =C2=A0 The reason you've given here certainly doesn't seem= convincing.

If a DHCPv6-only scenario is presented, th= en it needs to be stated that the nodes will not have any off-link connecti= vity, and thus that this scenario is possibly of limited use.

--089e013a1f1649f09404edb3166c-- From v6ops@globis.net Mon Dec 16 23:48:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137081AE0EF for ; Mon, 16 Dec 2013 23:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCUUalJoHkXy for ; Mon, 16 Dec 2013 23:48:13 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0D41AE0F7 for ; Mon, 16 Dec 2013 23:48:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 39731870F96; Tue, 17 Dec 2013 08:48:10 +0100 (CET) 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 N0xi8jgOYzjO; Tue, 17 Dec 2013 08:48:10 +0100 (CET) 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 E972887005B; Tue, 17 Dec 2013 08:48:09 +0100 (CET) Message-ID: <52B001B8.7030602@globis.net> Date: Tue, 17 Dec 2013 08:48:08 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Andrew Yourtchenko References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 07:48:15 -0000 Andrew Yourtchenko wrote: > Hello all, > > Finally I managed to comb a little bit and finally submit the doc that > aims to compare RAs with DHCPv6 which emerged from the discussion on > this list a few weeks ago. > > I'll be very happy to hear any comments, suggestions, flames, etc. > > --a I think the draft will be useful if 1) it allows an operator to make an informed choice 2) it identifies areas for future work With that in mind for 1) As a general remark after reading the comments to the list so far, there seems to be an underlying assumption that there's only one way to run a network, and that the infrastructure stack of Hosts/ LAN / MAN/ WAN/ DHCPv6/ DNS/ IPAM / Printers are all run by a single authority, and thus integration and change costs are effectively zero. IMHO "all combinations are possible" as used in an advert by a local supermarket. These infrastructure elements are usually run on behalf of a single authority in my experience, but if your LAN routers are not run by the same people as your IPAM and DNS, you might well want to make different trade offs with respect to what information is communicated by RA and what by DHCPv6, and what requests are relayed to a central instance and what is configured in a distributed manner on the local boxes. I think the pure technical discussions miss the impact on the management model mentioned in 2.10. I'd like to see an addition of some sample management models, where the infrastructure is run by different parties (this is v6ops after all). e.g. if you can set up your LAN routers to set up their interfaces using PD (with all information loaded from IPAM) plus a couple of DHCPv6 relay commands for the rest (also potentially loaded/learned from IPAM) I could imagine considerable costs savings in large environments. Whereas in a highly distributed environment, IPAM may not even make any sense at all, and local configuration via RA and local config files only might be extremely useful and cost effective. Provisioning is a major network cost. However that choice in turn is likely to impact the ease of renumbering in the future (a major bugbear of IPv4). It will also impact what protocols a travelling end node will have to support (code bloat). 2) I also think the areas of future work would be filled quicker if we examine the alternative approaches, and filled in the complete picture. So I'd suggest we look at the complete end to end picture needed to roll out and support the following combinations a) Central model: everything configured centrally as far as possible, with zero configuration information that is likely to change stored locally (configure local LAN switch once and forget, plus central IPAM DNS etc. for changes) You'll then hit the "How does an end node learn a default route?" and thus "how does the RA daemon learn it's prefix information?" type questions Think Meraki cloud controlled devices. b) Distributed model: everything configured locally on the local LAN switch or router (no IPAM required) You'll then hit the "how is DNS updated?" type questions. c) download model: hosts actively grab an XML file via HTTP for their "extended" configuration (or use AD). d) stand alone (disconnected) model: there is no router. You'll then hit the "How do I elect a DNS server?" and "why not use zeroconf?" type questions There is considerable overlap here with Homenet....... although the focus could be specifically on address assignment and the interactions between end nodes and routers. -- Regards, RayH From leo.liubing@huawei.com Mon Dec 16 23:58:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F361AE0FC for ; Mon, 16 Dec 2013 23:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4l23srfSTuQ for ; Mon, 16 Dec 2013 23:58:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DFADA1AE0F7 for ; Mon, 16 Dec 2013 23:58:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBM93590; Tue, 17 Dec 2013 07:58:00 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 07:57:22 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 07:57:35 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 15:57:29 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti , Ted Lemon Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO8PcjWuMJf8I9f0eBAQAUd5rlEZpWADIAgAGs+wD//5YhgIAAht9g//+EgICAAAOWgIAAAQAAgACsAXA= Date: Tue, 17 Dec 2013 07:57:28 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825D62nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 07:58:06 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825D62nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMTcsIDIwMTMgMTI6MDkgUE0NClRvOiBUZWQgTGVtb24NCkNjOiBM aXViaW5nIChMZW8pOyBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xz LmlldGYub3JnOyB2Nm9wc0BpZXRmLm9yZyBXRw0KU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRy YWZ0OiBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtDQoNCk9uIFR1ZSwgRGVj IDE3LCAyMDEzIGF0IDE6MDQgUE0sIFRlZCBMZW1vbiA8dGVkLmxlbW9uQG5vbWludW0uY29tPG1h aWx0bzp0ZWQubGVtb25Abm9taW51bS5jb20+PiB3cm90ZToNCj4gQnV0IHRoYXQgZHJhZnQgZGlk IG5vdCByZWFjaCBjb25zZW5zdXMgYW5kIGlzIG5vIGxvbmdlciBhbiBhY3RpdmUgd29ya2luZyBn cm91cCBpdGVtLCBzbyBpdCdzIHVubGlrZWx5IHRvIGhhcHBlbiBhbnkgdGltZSBzb29uLiBJZiB0 aGlzIHVzZSBjYXNlIG9ubHkgbWFrZXMgc2Vuc2UgaWYgcm91dGluZyBpcyBjb25maWd1cmVkIHdp dGggREhDUHY2LCB0aGVuIHRoZSB1c2UgY2FzZSBzaG91bGQgYmUgcmVtb3ZlZC4NCkkgdGhpbmsg dGhlIHVzZSBjYXNlIG1ha2VzIHNlbnNlIGluIGFuIGlzb2xhdGVkIG5ldHdvcmsuICAgUkEgbWln aHQgYmUgYSBiZXR0ZXIgY2hvaWNlLCBhbmQgaW5kZWVkIHdpdGhvdXQgUkEgSSB0aGluayBpdCBw cm9iYWJseSBkb2Vzbid0IHdvcmssIGJ1dCBJIGRvbid0IHNlZSB3aHkgdGhpcyBkb2N1bWVudCBz aG91bGRuJ3QgbWVudGlvbiB0aGlzIHVzZSBjYXNlLiAgIFRoZSByZWFzb24geW91J3ZlIGdpdmVu IGhlcmUgY2VydGFpbmx5IGRvZXNuJ3Qgc2VlbSBjb252aW5jaW5nLg0KDQpJZiBhIERIQ1B2Ni1v bmx5IHNjZW5hcmlvIGlzIHByZXNlbnRlZCwgdGhlbiBpdCBuZWVkcyB0byBiZSBzdGF0ZWQgdGhh dCB0aGUgbm9kZXMgd2lsbCBub3QgaGF2ZSBhbnkgb2ZmLWxpbmsgY29ubmVjdGl2aXR5LCBhbmQg dGh1cyB0aGF0IHRoaXMgc2NlbmFyaW8gaXMgcG9zc2libHkgb2YgbGltaXRlZCB1c2UuDQpbQmlu Z10gSXNvbGF0ZWQgbmV0d29yayBpcyBpbmRlZWQgYSB2YWxpZCB1c2UgY2FzZSwgdGhhbmtzIFRl ZCBmb3IgbWVudGlvbmluZyB0aGlzLg0KUmVnYXJkbGVzcyBvZiBzcGVjaWZpYyB1c2UgY2FzZXMs IGZvciB0aGUgYmVoYXZpb3Ig4oCcUkEgaXMgcmVxdWlyZWQgZm9yIGluaXRpYWxpbmcgREhDUHY2 4oCdLCBJIHRoaW5rOg0KMS4gVGhlIGRlcGVuZGVuY3kgaXMgbm90IHF1aXRlIHJlYXNvbmFibGU7 DQoyLiBXaGV0aGVyIHRoZXJlIHNob3VsZCBiZSBkZXBlbmRlbmN5IGlzIGFtYmlndW91cyBpbiBz dGFuZGFyZCwgYW5kIGl0IGlzIHdoeSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBoYXZlIHZhcmll ZCBvbiB0aGlzIGlzc3VlIChzb21lIHdpbGwgaW5pdGlhdGUgREhDUHY2IGlmIG5vIFJBOyBzb21l IGp1c3QgZG8gbm90aGluZykuDQoNCkJlc3QgUmVnYXJkcywNCkJpbmcNCg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825D62nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkg W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RGVjZW1iZXIgMTcsIDIwMTMgMTI6MDkgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlZCBMZW1vbjxicj4N CjxiPkNjOjwvYj4gTGl1YmluZyAoTGVvKTsgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMt cHJvYmxlbUB0b29scy5pZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcgV0c8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFh Yy1wcm9ibGVtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+T24gVHVlLCBEZWMgMTcsIDIwMTMgYXQgMTowNCBQTSwgVGVkIExlbW9uICZsdDs8 YSBocmVmPSJtYWlsdG86dGVkLmxlbW9uQG5vbWludW0uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGVk LmxlbW9uQG5vbWludW0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQnV0IHRoYXQgZHJhZnQgZGlkIG5vdCByZWFjaCBjb25z ZW5zdXMgYW5kIGlzIG5vIGxvbmdlciBhbiBhY3RpdmUgd29ya2luZyBncm91cCBpdGVtLCBzbyBp dCdzIHVubGlrZWx5IHRvIGhhcHBlbiBhbnkgdGltZSBzb29uLiBJZiB0aGlzIHVzZSBjYXNlIG9u bHkgbWFrZXMgc2Vuc2UgaWYgcm91dGluZyBpcyBjb25maWd1cmVkDQogd2l0aCBESENQdjYsIHRo ZW4gdGhlIHVzZSBjYXNlIHNob3VsZCBiZSByZW1vdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsg dGhlIHVzZSBjYXNlIG1ha2VzIHNlbnNlIGluIGFuIGlzb2xhdGVkIG5ldHdvcmsuICZuYnNwOyBS QSBtaWdodCBiZSBhIGJldHRlciBjaG9pY2UsIGFuZCBpbmRlZWQgd2l0aG91dCBSQSBJIHRoaW5r IGl0IHByb2JhYmx5IGRvZXNuJ3Qgd29yaywgYnV0IEkgZG9uJ3Qgc2VlIHdoeSB0aGlzIGRvY3Vt ZW50IHNob3VsZG4ndCBtZW50aW9uIHRoaXMgdXNlIGNhc2UuICZuYnNwOyBUaGUNCiByZWFzb24g eW91J3ZlIGdpdmVuIGhlcmUgY2VydGFpbmx5IGRvZXNuJ3Qgc2VlbSBjb252aW5jaW5nLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIGEgREhDUHY2LW9ubHkgc2Nl bmFyaW8gaXMgcHJlc2VudGVkLCB0aGVuIGl0IG5lZWRzIHRvIGJlIHN0YXRlZCB0aGF0IHRoZSBu b2RlcyB3aWxsIG5vdCBoYXZlIGFueSBvZmYtbGluayBjb25uZWN0aXZpdHksIGFuZCB0aHVzIHRo YXQgdGhpcyBzY2VuYXJpbyBpcyBwb3NzaWJseSBvZiBsaW1pdGVkIHVzZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBJc29sYXRlZCBuZXR3b3JrIGlz IGluZGVlZCBhIHZhbGlkIHVzZSBjYXNlLCB0aGFua3MgVGVkIGZvciBtZW50aW9uaW5nIHRoaXMu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZGxlc3Mg b2Ygc3BlY2lmaWMgdXNlIGNhc2VzLCBmb3IgdGhlIGJlaGF2aW9yIOKAnFJBIGlzIHJlcXVpcmVk IGZvciBpbml0aWFsaW5nIERIQ1B2NuKAnSwgSSB0aGluazoNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MS4gVGhlIGRlcGVuZGVuY3kgaXMgbm90IHF1aXRlIHJl YXNvbmFibGU7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIu IFdoZXRoZXIgdGhlcmUgc2hvdWxkIGJlIGRlcGVuZGVuY3kgaXMgYW1iaWd1b3VzIGluIHN0YW5k YXJkLCBhbmQgaXQgaXMgd2h5IGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGhhdmUgdmFyaWVkIG9u IHRoaXMgaXNzdWUgKHNvbWUgd2lsbCBpbml0aWF0ZQ0KIERIQ1B2NiBpZiBubyBSQTsgc29tZSBq dXN0IGRvIG5vdGhpbmcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0 IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CaW5n PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825D62nkgeml506mbxchi_-- From lorenzo@google.com Tue Dec 17 00:28:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6F1AE127 for ; Tue, 17 Dec 2013 00:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5_4458tXX5a for ; Tue, 17 Dec 2013 00:28:09 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 975961AE128 for ; Tue, 17 Dec 2013 00:28:09 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id j1so5799618iga.2 for ; Tue, 17 Dec 2013 00:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GPOixQ0P0N9SAfspn2+3v7O02AFI3N7lF0J6+G2w+IY=; b=YMVGGhaB1yP9Oq6o45h4XqQ06yTdOWRgDDVdgPv7nPpxwwqPHmU0n51hSH7DlpzjM2 xwZZ54Lyb42lncPIlzPLSrhdxOpIN2udsIXefmgApneP1Jtz1IVE6NfYy07I4NPfj6rD dKaQrkY/KDy2yMHP62/9QAZxUW963eJqgtQsqjQEWribPGU5hrbWBqjOYVvp1VTvh4ZE 12XWPDAR6pOl9h7eXV1RlZOHPJLsky2iQFDjYbOeU+vIRRL/ZkA3M2SV6nEvm4FiwrEY QbuZvx4F2UiOPEsnqxZFzVddZ1M2neTEtsTNnpTf6Lbl2JtMiMFSa+LJscMunRWmDowH IlZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GPOixQ0P0N9SAfspn2+3v7O02AFI3N7lF0J6+G2w+IY=; b=d3QRXxct+KdbIod4+CtWdCzyUOkwIQ5pq3Pp0XNwEHmgCLTFzI07Y0STxUfUgo4/Fp xAY9okWLOS9Mmo9oum6cIt5eXYHSa1WQWnBDN/0C5PxKarObGyy8WKbtiGmtPQpv+Yqy PS1Xb92k7UZj3waru5+dzyuO68OMC0Cl7Xd6rp1trB+mCWz/k4Whn59gaP4XEOJzRfJH 4y3EiUZrMcNOUcYfpK1Q2Xq0iRiCOYKjPvY2SJHjTe4bRTUootsp7Cpg9tpnDxHrSTWC cP5z4jr1OVfv9pj6SPKu9/REze7DZxc9UiqsFWDvF590Q8jxv+pETeACbGbM530UtSzN dfZQ== X-Gm-Message-State: ALoCoQmH53b+A6Iq9A8FNKgVkb1MmYJu2C+L1hHndlKcgVOUvcOTyu2CEso411oSMr6fw3HryEtdG3iOv7J6rLK/IPmQqHLjLl62eJiJYraS4y/Sj9GZjvoEk7f1mhg7b7AEZhxeev+ctVb92ipjXarr/DewC9rfvcSrCqdyzEcHTFBsV7YGa+/iZYUHTxxrPCBwYC2DY4+r X-Received: by 10.42.214.202 with SMTP id hb10mr406170icb.76.1387268888589; Tue, 17 Dec 2013 00:28:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Tue, 17 Dec 2013 00:27:48 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 17 Dec 2013 17:27:48 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=20cf301cc3b250141904edb6b563 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 08:28:11 -0000 --20cf301cc3b250141904edb6b563 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 17, 2013 at 4:57 PM, Liubing (Leo) wrot= e: > If a DHCPv6-only scenario is presented, then it needs to be stated > that the nodes will not have any off-link connectivity, and thus that thi= s > scenario is possibly of limited use. > > [Bing] Isolated network is indeed a valid use case, thanks Ted for > mentioning this. > Do you really want to mention this as a use case? What's the point of setting up a DHCPv6 server if the addresses it assigns can't talk to anything off-link anyway? If you do insist on mentioning it, please make it very clear that such a use case does not permit any sort of communication outside the link (not "outside the network" - "outside the link"), and that the you don't need to configure a DHCPv6 server to do that - you can just use link-local addresses, which are created automatically. > Regardless of specific use cases, for the behavior =E2=80=9CRA is requi= red for > initialing DHCPv6=E2=80=9D, I think: > > 1. The dependency is not quite reasonable; > I don't think it's unreasonable, because an RA is needed for connectivity anyway. Also, if there is no IPv6 off-link connectivity but there is IPv4 off-link connectivity, then it's better for hosts *not* to have an IPv6 address. This is because if they do have an IPv6 address, then they will waste their time doing AAAA lookups for off-link destinations which they can't reach. > 2. Whether there should be dependency is ambiguous in standard, and it > is why current implementations have varied on this issue (some will > initiate DHCPv6 if no RA; some just do nothing). > I don't think this is a big problem, since if there is no router there's no off-link connectivity, and a network without off-link connectivity is not very useful. --20cf301cc3b250141904edb6b563 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 17, 2013 at 4:57 PM, Liubing (Leo) <leo.liubing@huawei.com> wrote:

If a DHCPv6-only = scenario is presented, then it needs to be stated that the nodes will not h= ave any off-link connectivity, and thus that this scenario is possibly of l= imited use.

[Bing] Isolated network is indeed a valid use case, thanks Ted f= or mentioning this.


Do you really want= to mention this as a use case? What's the point of setting up a DHCPv6= server if the addresses it assigns can't talk to anything off-link any= way?

If you do insist on mentioning it, please make it very = clear that such a use case does not permit any sort of communication outsid= e the link (not "outside the network" - "outside the link&qu= ot;), and that the you don't need to configure a DHCPv6 server to do th= at - you can just use link-local addresses, which are created automatically= .
=C2=A0

Regardless= of specific use cases, for the behavior =E2=80=9CRA is required for initia= ling DHCPv6=E2=80=9D, I think:

1. The dep= endency is not quite reasonable;


I don't think it's unreasona= ble, because an RA is needed for connectivity anyway. Also, if there is no = IPv6 off-link connectivity but there is IPv4 off-link connectivity, then it= 's better for hosts *not* to have an IPv6 address. This is because if t= hey do have an IPv6 address, then they will waste their time doing AAAA loo= kups for off-link destinations which they can't reach.
=C2=A0

2. Whether= there should be dependency is ambiguous in standard, and it is why current= implementations have varied on this issue (some will initiate DHCPv6 if no RA; some just do nothing).

=

I don't think this i= s a big problem, since if there is no router there's no off-link connec= tivity, and a network without off-link connectivity is not very useful.
--20cf301cc3b250141904edb6b563-- From tore@fud.no Tue Dec 17 01:52:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87581ADFBE for ; Tue, 17 Dec 2013 01:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fREznHmrmrnc for ; Tue, 17 Dec 2013 01:52:57 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 250A21ADFB2 for ; Tue, 17 Dec 2013 01:52:57 -0800 (PST) Received: from [2a02:fe0:c410:1d30:b6b6:76ff:fe17:2e83] (port=47636 helo=sloth.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VsrKe-0003MF-Bp; Tue, 17 Dec 2013 10:52:52 +0100 Message-ID: <52B01EF3.6030205@fud.no> Date: Tue, 17 Dec 2013 10:52:51 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Lorenzo Colitti , "Liubing (Leo)" References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 09:52:58 -0000 * Lorenzo Colitti > Do you really want to mention this as a use case? What's the point of > setting up a DHCPv6 server if the addresses it assigns can't talk to > anything off-link anyway? It's not only off-link communication that won't work in a RA-less network. Two nodes on the same link cannot even communicate bidirectionally with each other using their DHCPv6-asssigned addresses. For that to work a RA carrying a PIO with L=1 needs to be present. Tore From leo.liubing@huawei.com Tue Dec 17 02:03:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA951AE127 for ; Tue, 17 Dec 2013 02:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73vb8m0gcA2P for ; Tue, 17 Dec 2013 02:03:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D904B1AE0EF for ; Tue, 17 Dec 2013 02:03:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZC15166; Tue, 17 Dec 2013 10:03:31 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 10:03:02 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 10:03:29 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 18:03:24 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO8PcjWuMJf8I9f0eBAQAUd5rlEZpWADIAgAGs+wD//5YhgIAAht9g//+EgICAAAOWgIAAAQAAgACsAXD//5xtAAAS/iZA Date: Tue, 17 Dec 2013 10:03:24 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:03:36 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMTcsIDIwMTMgNDoyOCBQTQ0KVG86IExpdWJpbmcgKExlbykNCkNj OiBUZWQgTGVtb247IHY2b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcg ZHJhZnQ6IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0NCg0KT24gVHVlLCBE ZWMgMTcsIDIwMTMgYXQgNDo1NyBQTSwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2Vp LmNvbTxtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSWYgYSBESENQdjYt b25seSBzY2VuYXJpbyBpcyBwcmVzZW50ZWQsIHRoZW4gaXQgbmVlZHMgdG8gYmUgc3RhdGVkIHRo YXQgdGhlIG5vZGVzIHdpbGwgbm90IGhhdmUgYW55IG9mZi1saW5rIGNvbm5lY3Rpdml0eSwgYW5k IHRodXMgdGhhdCB0aGlzIHNjZW5hcmlvIGlzIHBvc3NpYmx5IG9mIGxpbWl0ZWQgdXNlLg0KW0Jp bmddIElzb2xhdGVkIG5ldHdvcmsgaXMgaW5kZWVkIGEgdmFsaWQgdXNlIGNhc2UsIHRoYW5rcyBU ZWQgZm9yIG1lbnRpb25pbmcgdGhpcy4NCg0KRG8geW91IHJlYWxseSB3YW50IHRvIG1lbnRpb24g dGhpcyBhcyBhIHVzZSBjYXNlPw0KW0JpbmddIFllcy4NCg0KV2hhdCdzIHRoZSBwb2ludCBvZiBz ZXR0aW5nIHVwIGEgREhDUHY2IHNlcnZlciBpZiB0aGUgYWRkcmVzc2VzIGl0IGFzc2lnbnMgY2Fu J3QgdGFsayB0byBhbnl0aGluZyBvZmYtbGluayBhbnl3YXk/DQpbQmluZ10gSXQgbWlnaHQgYmUg bm9uc2Vuc2UgZm9yIHlvdSwgYnV0IHlvdSBuZXZlciBrbm93IHdobyBtaWdodCBuZWVkIHRoaXMg dXNlIGNhc2UuIEFuZCBmb3IgdGhpcyBkb2N1bWVudCwgaXQgaXMgbm90IGEgZ29hbCB0byBqdWRn ZSB0aGUgdXNlIGNhc2UgdmFsaWQgb3Igbm90LCBidXQgdG8gcHJvdmlkZSBjYXV0aW9ucyB0aGF0 IHRoZXJlIG1pZ2h0IGJlIHByb2JsZW0gaW4gdGhlc2Ugb3IgdGhvc2UgY2FzZXMuDQoNCklmIHlv dSBkbyBpbnNpc3Qgb24gbWVudGlvbmluZyBpdCwgcGxlYXNlIG1ha2UgaXQgdmVyeSBjbGVhciB0 aGF0IHN1Y2ggYSB1c2UgY2FzZSBkb2VzIG5vdCBwZXJtaXQgYW55IHNvcnQgb2YgY29tbXVuaWNh dGlvbiBvdXRzaWRlIHRoZSBsaW5rIChub3QgIm91dHNpZGUgdGhlIG5ldHdvcmsiIC0gIm91dHNp ZGUgdGhlIGxpbmsiKSwgYW5kIHRoYXQgdGhlIHlvdSBkb24ndCBuZWVkIHRvIGNvbmZpZ3VyZSBh IERIQ1B2NiBzZXJ2ZXIgdG8gZG8gdGhhdCAtIHlvdSBjYW4ganVzdCB1c2UgbGluay1sb2NhbCBh ZGRyZXNzZXMsIHdoaWNoIGFyZSBjcmVhdGVkIGF1dG9tYXRpY2FsbHkuDQoNClJlZ2FyZGxlc3Mg b2Ygc3BlY2lmaWMgdXNlIGNhc2VzLCBmb3IgdGhlIGJlaGF2aW9yIOKAnFJBIGlzIHJlcXVpcmVk IGZvciBpbml0aWFsaW5nIERIQ1B2NuKAnSwgSSB0aGluazoNCjEuIFRoZSBkZXBlbmRlbmN5IGlz IG5vdCBxdWl0ZSByZWFzb25hYmxlOw0KDQpJIGRvbid0IHRoaW5rIGl0J3MgdW5yZWFzb25hYmxl LCBiZWNhdXNlIGFuIFJBIGlzIG5lZWRlZCBmb3IgY29ubmVjdGl2aXR5IGFueXdheS4NCltCaW5n XSBGaXJzdCwgeW91IGNhbiBuZXZlciB0b3RhbGx5IGRlbnkgdGhlIGNhc2VzIHRoYXQgdGhlcmXi gJlzIG5vIFJBIGJ1dCBESENQdjYgaXMgbmVlZGVkLCBlc3BlY2lhbGx5IGluIHRoZSBmdXR1cmUu IFNlY29uZCwgZXZlbiBhc3N1bWluZyBSQSBpcyBuZWVkZWQgZm9yIGNvbm5lY3Rpdml0eSwgc3Rp bGwgZG9lc27igJl0IG1lYW4gUkEgU0hPVUxEIGJlIG5lZWRlZCBmb3IgdHJpZ2dlcmluZyBESENQ djYuIEkgdGhpbmsgaXQgd291bGQgcmVkdWNlIHRoZSByb2J1c3Qgb2YgREhDUCBzZXJ2aWNlLCBl LmcuIHdoYXQgaWYgdGhlIE0gZmxhZyB3YXMgbWlzY29uZmlndXJlZC4NCg0KQmVzdCBSZWdhcmRz LA0KQmluZw0KDQpBbHNvLCBpZiB0aGVyZSBpcyBubyBJUHY2IG9mZi1saW5rIGNvbm5lY3Rpdml0 eSBidXQgdGhlcmUgaXMgSVB2NCBvZmYtbGluayBjb25uZWN0aXZpdHksIHRoZW4gaXQncyBiZXR0 ZXIgZm9yIGhvc3RzICpub3QqIHRvIGhhdmUgYW4gSVB2NiBhZGRyZXNzLiBUaGlzIGlzIGJlY2F1 c2UgaWYgdGhleSBkbyBoYXZlIGFuIElQdjYgYWRkcmVzcywgdGhlbiB0aGV5IHdpbGwgd2FzdGUg dGhlaXIgdGltZSBkb2luZyBBQUFBIGxvb2t1cHMgZm9yIG9mZi1saW5rIGRlc3RpbmF0aW9ucyB3 aGljaCB0aGV5IGNhbid0IHJlYWNoLg0KDQoyLiBXaGV0aGVyIHRoZXJlIHNob3VsZCBiZSBkZXBl bmRlbmN5IGlzIGFtYmlndW91cyBpbiBzdGFuZGFyZCwgYW5kIGl0IGlzIHdoeSBjdXJyZW50IGlt cGxlbWVudGF0aW9ucyBoYXZlIHZhcmllZCBvbiB0aGlzIGlzc3VlIChzb21lIHdpbGwgaW5pdGlh dGUgREhDUHY2IGlmIG5vIFJBOyBzb21lIGp1c3QgZG8gbm90aGluZykuDQoNCkkgZG9uJ3QgdGhp bmsgdGhpcyBpcyBhIGJpZyBwcm9ibGVtLCBzaW5jZSBpZiB0aGVyZSBpcyBubyByb3V0ZXIgdGhl cmUncyBubyBvZmYtbGluayBjb25uZWN0aXZpdHksIGFuZCBhIG5ldHdvcmsgd2l0aG91dCBvZmYt bGluayBjb25uZWN0aXZpdHkgaXMgbm90IHZlcnkgdXNlZnVsLg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkg W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RGVjZW1iZXIgMTcsIDIwMTMgNDoyOCBQTTxicj4NCjxiPlRvOjwvYj4gTGl1YmluZyAoTGVvKTxi cj4NCjxiPkNjOjwvYj4gVGVkIExlbW9uOyB2Nm9wc0BpZXRmLm9yZyBXRzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNs YWFjLXByb2JsZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBUdWUsIERlYyAxNywgMjAxMyBhdCA0OjU3IFBNLCBMaXViaW5nIChMZW8p ICZsdDs8YSBocmVmPSJtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmxlby5saXViaW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM1MDAwNTAiPklmIGEgREhDUHY2LW9ubHkgc2NlbmFyaW8g aXMgcHJlc2VudGVkLCB0aGVuIGl0IG5lZWRzIHRvIGJlIHN0YXRlZCB0aGF0IHRoZSBub2RlcyB3 aWxsIG5vdCBoYXZlIGFueSBvZmYtbGluayBjb25uZWN0aXZpdHksIGFuZCB0aHVzIHRoYXQNCiB0 aGlzIHNjZW5hcmlvIGlzIHBvc3NpYmx5IG9mIGxpbWl0ZWQgdXNlLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JpbmddIElzb2xhdGVkIG5ldHdvcmsgaXMgaW5kZWVkIGEg dmFsaWQgdXNlIGNhc2UsIHRoYW5rcyBUZWQgZm9yIG1lbnRpb25pbmcgdGhpcy48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RG8geW91IHJlYWxseSB3YW50IHRvIG1l bnRpb24gdGhpcyBhcyBhIHVzZSBjYXNlPw0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBZ ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+V2hhdCdzIHRoZSBwb2ludCBvZiBzZXR0aW5nIHVwIGEgREhDUHY2IHNlcnZlciBpZiB0aGUg YWRkcmVzc2VzIGl0IGFzc2lnbnMgY2FuJ3QgdGFsayB0byBhbnl0aGluZyBvZmYtbGluayBhbnl3 YXk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQmluZ10gSXQg bWlnaHQgYmUgbm9uc2Vuc2UgZm9yIHlvdSwgYnV0IHlvdSBuZXZlciBrbm93IHdobyBtaWdodCBu ZWVkIHRoaXMgdXNlIGNhc2UuIEFuZCBmb3IgdGhpcyBkb2N1bWVudCwgaXQgaXMgbm90IGEgZ29h bCB0byBqdWRnZSB0aGUgdXNlDQogY2FzZSB2YWxpZCBvciBub3QsIGJ1dCB0byBwcm92aWRlIGNh dXRpb25zIHRoYXQgdGhlcmUgbWlnaHQgYmUgcHJvYmxlbSBpbiB0aGVzZSBvciB0aG9zZSBjYXNl cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYg eW91IGRvIGluc2lzdCBvbiBtZW50aW9uaW5nIGl0LCBwbGVhc2UgbWFrZSBpdCB2ZXJ5IGNsZWFy IHRoYXQgc3VjaCBhIHVzZSBjYXNlIGRvZXMgbm90IHBlcm1pdCBhbnkgc29ydCBvZiBjb21tdW5p Y2F0aW9uIG91dHNpZGUgdGhlIGxpbmsgKG5vdCAmcXVvdDtvdXRzaWRlIHRoZSBuZXR3b3JrJnF1 b3Q7IC0gJnF1b3Q7b3V0c2lkZSB0aGUgbGluayZxdW90OyksIGFuZCB0aGF0IHRoZSB5b3UgZG9u J3QgbmVlZA0KIHRvIGNvbmZpZ3VyZSBhIERIQ1B2NiBzZXJ2ZXIgdG8gZG8gdGhhdCAtIHlvdSBj YW4ganVzdCB1c2UgbGluay1sb2NhbCBhZGRyZXNzZXMsIHdoaWNoIGFyZSBjcmVhdGVkIGF1dG9t YXRpY2FsbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmVnYXJkbGVzcyBvZiBzcGVjaWZpYyB1c2UgY2FzZXMsIGZvciB0aGUgYmVoYXZpb3Ig4oCcUkEg aXMgcmVxdWlyZWQgZm9yIGluaXRpYWxpbmcgREhDUHY24oCdLA0KIEkgdGhpbms6IDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjEuIFRoZSBkZXBlbmRlbmN5IGlzIG5vdCBxdWl0ZSByZWFzb25hYmxlOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5JIGRvbid0IHRoaW5rIGl0J3MgdW5yZWFzb25hYmxlLCBiZWNhdXNl IGFuIFJBIGlzIG5lZWRlZCBmb3IgY29ubmVjdGl2aXR5IGFueXdheS4NCjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bQmluZ10gRmlyc3QsIHlvdSBjYW4gbmV2ZXIgdG90YWxseSBkZW55IHRoZSBjYXNl cyB0aGF0IHRoZXJl4oCZcyBubyBSQSBidXQgREhDUHY2IGlzIG5lZWRlZCwgZXNwZWNpYWxseSBp biB0aGUgZnV0dXJlLiBTZWNvbmQsIGV2ZW4gYXNzdW1pbmcgUkENCiBpcyBuZWVkZWQgZm9yIGNv bm5lY3Rpdml0eSwgc3RpbGwgZG9lc27igJl0IG1lYW4gUkEgU0hPVUxEIGJlIG5lZWRlZCBmb3Ig dHJpZ2dlcmluZyBESENQdjYuIEkgdGhpbmsgaXQgd291bGQgcmVkdWNlIHRoZSByb2J1c3Qgb2Yg REhDUCBzZXJ2aWNlLCBlLmcuIHdoYXQgaWYgdGhlIE0gZmxhZyB3YXMgbWlzY29uZmlndXJlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmluZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsc28sIGlmIHRoZXJlIGlz IG5vIElQdjYgb2ZmLWxpbmsgY29ubmVjdGl2aXR5IGJ1dCB0aGVyZSBpcyBJUHY0IG9mZi1saW5r IGNvbm5lY3Rpdml0eSwgdGhlbiBpdCdzIGJldHRlciBmb3IgaG9zdHMgKm5vdCogdG8gaGF2ZSBh biBJUHY2IGFkZHJlc3MuIFRoaXMgaXMgYmVjYXVzZSBpZiB0aGV5IGRvIGhhdmUgYW4gSVB2NiBh ZGRyZXNzLCB0aGVuIHRoZXkgd2lsbCB3YXN0ZQ0KIHRoZWlyIHRpbWUgZG9pbmcgQUFBQSBsb29r dXBzIGZvciBvZmYtbGluayBkZXN0aW5hdGlvbnMgd2hpY2ggdGhleSBjYW4ndCByZWFjaC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLiBXaGV0aGVyIHRo ZXJlIHNob3VsZCBiZSBkZXBlbmRlbmN5IGlzIGFtYmlndW91cyBpbiBzdGFuZGFyZCwgYW5kIGl0 IGlzIHdoeSBjdXJyZW50DQogaW1wbGVtZW50YXRpb25zIGhhdmUgdmFyaWVkIG9uIHRoaXMgaXNz dWUgKHNvbWUgd2lsbCBpbml0aWF0ZSBESENQdjYgaWYgbm8gUkE7IHNvbWUganVzdCBkbyBub3Ro aW5nKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBkb24ndCB0aGluayB0aGlzIGlzIGEgYmln IHByb2JsZW0sIHNpbmNlIGlmIHRoZXJlIGlzIG5vIHJvdXRlciB0aGVyZSdzIG5vIG9mZi1saW5r IGNvbm5lY3Rpdml0eSwgYW5kIGEgbmV0d29yayB3aXRob3V0IG9mZi1saW5rIGNvbm5lY3Rpdml0 eSBpcyBub3QgdmVyeSB1c2VmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8nkgeml506mbxchi_-- From ayourtch@cisco.com Tue Dec 17 02:17:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD91AE153 for ; Tue, 17 Dec 2013 02:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow9rLf9az8xO for ; Tue, 17 Dec 2013 02:17:01 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 956401AE14B for ; Tue, 17 Dec 2013 02:17:01 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHAGxwj028979 for ; Tue, 17 Dec 2013 11:16:59 +0100 (CET) Received: from [10.61.223.174] ([10.61.223.174]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHAGrSP027023; Tue, 17 Dec 2013 11:16:54 +0100 (CET) Date: Tue, 17 Dec 2013 10:16:53 +0000 (WET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Tore Anderson In-Reply-To: <52B01EF3.6030205@fud.no> Message-ID: References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <52B01EF3.6030205@fud.no> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:17:03 -0000 On Tue, 17 Dec 2013, Tore Anderson wrote: > * Lorenzo Colitti > >> Do you really want to mention this as a use case? What's the point of >> setting up a DHCPv6 server if the addresses it assigns can't talk to >> anything off-link anyway? > > It's not only off-link communication that won't work in a RA-less > network. Two nodes on the same link cannot even communicate > bidirectionally with each other using their DHCPv6-asssigned addresses. > For that to work a RA carrying a PIO with L=1 needs to be present. Curiously, RFC 2461 had it completely the other way: section 6.3.6 "Default Router Selection", in the every end, says if there is no default router assume all the destinations are on-link. It was the RFC 4861 which has removed this paragraph. --a > > Tore > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Tue Dec 17 02:26:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2F11ADBCF for ; Tue, 17 Dec 2013 02:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6oL9n5xomIx for ; Tue, 17 Dec 2013 02:26:20 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 95DC21ADBC7 for ; Tue, 17 Dec 2013 02:26:20 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so5974117igb.0 for ; Tue, 17 Dec 2013 02:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AWIz3sk5fOrP+53GU64+JnX5NDRd5bVQRbM2JeUGjj0=; b=dbR3kHJYokx9J3VIi8ptWh1vUfqouITtwi/3toDWY0Ip3S+/2oUeVf2qfhy0RMvTQS o4Il4vdxOk4jofl4FkWBwF3JrODAcMTrs86XNVNfjrw6oBOF6QvqZNFJ/4/0K+360jxF lmWwtOlyidP1eqntmXK7mJPuBEFBvQlriW9tkpzu4fBoKw6JEKAt7sRrbuQAFh1ZcoWs xjZuvOQK4/I79UZYwjPLKBmX/rTvgXWh6ycSF9G+RwfwNT628u7vswKHya+jvbeeRnSd 2R3LHr6IEmCEU5jovBIvi9/x90tk39r9c3xCDr9jF+3EkwJl/spV1Pk9xGlMuomq7o91 WbRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AWIz3sk5fOrP+53GU64+JnX5NDRd5bVQRbM2JeUGjj0=; b=kFVDc/J/Ptg3Fv6NPaAvasYhWbTJhHcmy5wNHLViXPluULM6wkKk0VTMV4uI/HD8ay Ne4MrtnrrA9Hxm20Ze2bwsvWQDmA32OUKGrW6k0GG3KBmjyQXqUf6+9Z64gHqnHefgNJ MzJbivW0wLXxDn/10h0eDQumuW9l8RSvgn04USMFcgyq3ybwqm2ci8QaERlfRT8whfJy WwwxTWpdCLVemnO7BatEcxggoTEt9G9bRv3Hq1Mg++yxlsuQqu/EFbWWtzYEpBxw5Oxk d+gVPz1Qk9dCmvxGXkRetYMwzjgKtBEada60ESZpNRXHiVkv+vO+JXr5DSfFI8cJSJz4 Z3mg== X-Gm-Message-State: ALoCoQm8shsesHyxnI2cwd+VQ3eaJYnyZGBy26rvy78OjIRndQ7o1fvl/4e8XgOBn0g+7vAFtCJRngVwSPP4D3Rp57zOLrwrqoGTE2E8seRq67t31AbQ+lb7z7dJz7QsLag57gGClcOQyl2L0adisX5VupArZtMfAika3xQyBqKoRB4B8w6Bu9lB2LjjypRxm1BHgCD0sbef X-Received: by 10.43.103.67 with SMTP id dh3mr5142659icc.60.1387275979450; Tue, 17 Dec 2013 02:26:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Tue, 17 Dec 2013 02:25:59 -0800 (PST) In-Reply-To: References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <52B01EF3.6030205@fud.no> From: Lorenzo Colitti Date: Tue, 17 Dec 2013 19:25:59 +0900 Message-ID: To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=bcaec517201ff659e304edb85bc0 Cc: "v6ops@ietf.org WG" , Tore Anderson Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:26:22 -0000 --bcaec517201ff659e304edb85bc0 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 17, 2013 at 7:16 PM, Andrew Yourtchenko wrote: > Do you really want to mention this as a use case? What's the point of >>> setting up a DHCPv6 server if the addresses it assigns can't talk to >>> anything off-link anyway? >>> >> >> It's not only off-link communication that won't work in a RA-less >> network. Two nodes on the same link cannot even communicate >> bidirectionally with each other using their DHCPv6-asssigned addresses. >> For that to work a RA carrying a PIO with L=1 needs to be present. >> > > Curiously, RFC 2461 had it completely the other way: section 6.3.6 > "Default Router Selection", in the every end, says if there is no default > router assume all the destinations are on-link. > > It was the RFC 4861 which has removed this paragraph. > Hmm. http://tools.ietf.org/html/rfc4943 , "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful" --bcaec517201ff659e304edb85bc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 17, 2013 at 7:16 PM, Andrew Yourtchenko <ayourtch@cisco.com&g= t; wrote:
Do you really want to mention this as a use case? What'= ;s the point of
setting up a DHCPv6 server if the addresses it assigns can't talk to anything off-link anyway?

It's not only off-link communication that won't work in a RA-less network. Two nodes on the same link cannot even communicate
bidirectionally with each other using their DHCPv6-asssigned addresses.
For that to work a RA carrying a PIO with L=3D1 needs to be present.

Curiously, RFC 2461 had it completely the other way: section 6.3.6 "De= fault Router Selection", in the every end, says if there is no default= router assume all the destinations are on-link.

It was the RFC 4861 which has removed this paragraph.
=
Hmm. http://t= ools.ietf.org/html/rfc4943 , "IPv6 Neighbor Discovery On-Link Assu= mption Considered Harmful"
--bcaec517201ff659e304edb85bc0-- From lorenzo@google.com Tue Dec 17 02:29:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC29B1AE142 for ; Tue, 17 Dec 2013 02:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofkfueeyr1Y6 for ; Tue, 17 Dec 2013 02:29:21 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id A27B51ADBC7 for ; Tue, 17 Dec 2013 02:29:21 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so8025434iec.21 for ; Tue, 17 Dec 2013 02:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NrTkdKXQwA58uDnhRIU55vpZc7uSBuDyJgeol0GQ77A=; b=Ag2uWowgrzmptSlGn85EIEccY+gm2AnEKzxCvgaf81DUfdy+Fbozj39fV5/Fm5I20T CHxrDLt+EBkq/g+EuxEwoiOSkEPUE2ToGQN4knmPc9Ki9onalRYEW8VKa+1zoa5vxwCW DI2drEVItErJmsoL6Zq2jZRnsou6xrW3QYq9IILRq3GuAo5mUvisWVST6ZqlEANW9gah 8M+uacuzbztA8hLYQS8FWZNyJ8dJVNGZWFvvLaCELydC8OLGDZGV01QHQOwOOQdPcYhV TnqpbmaPIo+ouiVn3nU74hlJtoxjAIBXlE3QfsBDQMQUhGd5f7I1D1ANO0BwOsZMwov9 Arnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NrTkdKXQwA58uDnhRIU55vpZc7uSBuDyJgeol0GQ77A=; b=PVQe9p2Th8IvxdXLq7Eh0wV/BSn8tLmjImbBUle31tqBwjSGn2qdv/+kUCm91Pl3WZ +zcIf/JF9XwoSkA7K4ZdZL8ztxyzpc1EQj5Aj52kE0RG7+lkA2zBl4VdXT0e/tkWi1/p 9geEZ3sz/Mll3i+d2iGbTr+L9RMfxRvrGFksUMNUh2bFPqx6CtESIU0dkgi63HWpEyoG 7RO5Gn5SGBKI09E418fSuCKFc3cGAmLHQQIe7QeufYFxZy0hJEV92tIWPIzbUc0awSpX 6B3SVIKxGksOGpR9vQsGAQgm5Z9tXPMdZCwoKCTRVBar1VJEKh7JzRj4U4jEX2sk3mF/ FQxw== X-Gm-Message-State: ALoCoQmBU07sGu3YP8WAvSojvsi9+v0iR3nn6nQZUvHkH+dslerx1d9eEK5yQxDzCUlSbZLJqhOmUR8l10AeJ5uBqb0CKVCdtGXAtrRkV8V90FeZgrXiQ4A+kOwmN+9W71HcCp7sBu2Hx9daQPHgJ5wj7IGuECzAjyT9nkLnW1yjiFabX8HAtF06eC15wyWT/iwCrOACRZRJ X-Received: by 10.43.137.71 with SMTP id in7mr27601icc.97.1387276160571; Tue, 17 Dec 2013 02:29:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Tue, 17 Dec 2013 02:28:59 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 17 Dec 2013 19:28:59 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c25428c202f204edb8660d Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:29:23 -0000 --001a11c25428c202f204edb8660d Content-Type: text/plain; charset=UTF-8 On Tue, Dec 17, 2013 at 7:03 PM, Liubing (Leo) wrote: > Do you really want to mention this as a use case? > > [Bing] Yes. > > > > What's the point of setting up a DHCPv6 server if the addresses it assigns > can't talk to anything off-link anyway? > > [Bing] It might be nonsense for you, but you never know who might need > this use case. And for this document, it is not a goal to judge the use > case valid or not, but to provide cautions that there might be problem in > these or those cases. > I think Tore's comment makes it clear that those addresses won't work *at all*, not even for on-link communication. I strongly object to listing a use case that assigns addresses that don't work. --001a11c25428c202f204edb8660d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a11c25428c202f204edb8660d-- From ayourtch@cisco.com Tue Dec 17 02:45:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5B61ADBCF for ; Tue, 17 Dec 2013 02:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJaNkrHttwe0 for ; Tue, 17 Dec 2013 02:45:44 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E98741AE146 for ; Tue, 17 Dec 2013 02:45:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHAjgie002118 for ; Tue, 17 Dec 2013 11:45:42 +0100 (CET) Received: from [10.61.223.174] ([10.61.223.174]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHAjbFD010147; Tue, 17 Dec 2013 11:45:38 +0100 (CET) Date: Tue, 17 Dec 2013 10:45:37 +0000 (WET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Ray Hunter In-Reply-To: <52B001B8.7030602@globis.net> Message-ID: References: <52B001B8.7030602@globis.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:45:47 -0000 Thanks for the insight! inline. On Tue, 17 Dec 2013, Ray Hunter wrote: > Andrew Yourtchenko wrote: >> Hello all, >> >> Finally I managed to comb a little bit and finally submit the doc that >> aims to compare RAs with DHCPv6 which emerged from the discussion on >> this list a few weeks ago. >> >> I'll be very happy to hear any comments, suggestions, flames, etc. >> >> --a > I think the draft will be useful if > > 1) it allows an operator to make an informed choice > > 2) it identifies areas for future work > > With that in mind > > for 1) As a general remark after reading the comments to the list so > far, there seems to be an underlying assumption that there's only one > way to run a network, and that the infrastructure stack of Hosts/ LAN / > MAN/ WAN/ DHCPv6/ DNS/ IPAM / Printers are all run by a single > authority, and thus integration and change costs are effectively zero. > > IMHO "all combinations are possible" as used in an advert by a local > supermarket. These infrastructure elements are usually run on behalf of > a single authority in my experience, but if your LAN routers are not run > by the same people as your IPAM and DNS, you might well want to make > different trade offs with respect to what information is communicated by > RA and what by DHCPv6, and what requests are relayed to a central > instance and what is configured in a distributed manner on the local boxes. > > I think the pure technical discussions miss the impact on the management > model mentioned in 2.10. > > I'd like to see an addition of some sample management models, where the > infrastructure is run by different parties (this is v6ops after all). > e.g. if you can set up your LAN routers to set up their interfaces using > PD (with all information loaded from IPAM) plus a couple of DHCPv6 relay > commands for the rest (also potentially loaded/learned from IPAM) I > could imagine considerable costs savings in large environments. Whereas > in a highly distributed environment, IPAM may not even make any sense at > all, and local configuration via RA and local config files only might be > extremely useful and cost effective. Provisioning is a major network cost. > > However that choice in turn is likely to impact the ease of renumbering > in the future (a major bugbear of IPv4). It will also impact what > protocols a travelling end node will have to support (code bloat). I had just removed the entire management section, so this would be for the potential future. I am welcoming the texts describing the operational models that people use which I can include as an issue for now, for later, when the "semantics" are done. > > 2) I also think the areas of future work would be filled quicker if we > examine the alternative approaches, and filled in the complete picture. > > So I'd suggest we look at the complete end to end picture needed to roll > out and support the following combinations > > a) Central model: everything configured centrally as far as possible, > with zero configuration information that is likely to change stored > locally (configure local LAN switch once and forget, plus central IPAM > DNS etc. for changes) > You'll then hit the "How does an end node learn a default route?" and > thus "how does the RA daemon learn it's prefix information?" type questions > Think Meraki cloud controlled devices. > > b) Distributed model: everything configured locally on the local LAN > switch or router (no IPAM required) > You'll then hit the "how is DNS updated?" type questions. > > c) download model: hosts actively grab an XML file via HTTP for their > "extended" configuration (or use AD). > > d) stand alone (disconnected) model: there is no router. > You'll then hit the "How do I elect a DNS server?" and "why not use > zeroconf?" type questions This looks like two pairs across two independent axis ? (a-b, c-d) ? Also: if there's no router, there's no communication beyond the link. > > There is considerable overlap here with Homenet....... although the > focus could be specifically on address assignment and the interactions > between end nodes and routers. There were two goals: 1) "what are the inherent protocol properties of RA vs. DHCP" 2) "what to extend for new functionality, RA vs. DHCP ?" With the assumption the (1) would help to understand (2) better. Maybe. Now, looking at a-d above, I wonder whether the "new functionality" needs to be more tightly bound as a prerequisite to even (1). If I were writing a new app, I'd certainly try to avoid both RA and DHCP, in lieu of the download or zeroconf. If I am writing the new L3 protocol that needs to be provisioned - this is when I would start to consider "RA vs. DHCP". --a > > -- > Regards, > RayH > From ayourtch@cisco.com Tue Dec 17 03:12:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0C61ADEAE for ; Tue, 17 Dec 2013 03:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.839 X-Spam-Level: X-Spam-Status: No, score=-6.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U94WIpc3AFjy for ; Tue, 17 Dec 2013 03:12:46 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 468EC1AE148 for ; Tue, 17 Dec 2013 03:12:46 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHBCi7a004992 for ; Tue, 17 Dec 2013 12:12:44 +0100 (CET) Received: from [10.61.223.174] ([10.61.223.174]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBHBCgA9021842; Tue, 17 Dec 2013 12:12:43 +0100 (CET) Date: Tue, 17 Dec 2013 11:12:39 +0000 (WET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Brian E Carpenter In-Reply-To: <52AF9FAB.7060702@gmail.com> Message-ID: References: <20131127125213.17409.86382.idtracker@ietfa.amsl.com> <52AF9FAB.7060702@gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-yourtchenko-ra-dhcpv6-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 11:12:48 -0000 Hi, On Tue, 17 Dec 2013, Brian E Carpenter wrote: > Hi, > > (Still on v6ops, although 6man might be appropriate.) > yep. See my comment at the end. > I think that there are some topics quite deep inside the > draft that really belong nearer the beginning. After all, > these are the issues that will guide future work: do we add > feature X to RA, DHCPv6, or both?. > > In a logical order, these topics are: > > a) 4. Differences between different types of network operators > > b) 2.11. Scope of use / Applicability > (e.g. 2.7. Involvement or not into routing) > (e.g. to what extent do we want feature-equivalence > and a shared data model?) > > c) 2.10. Separate vs. unified management > > There may be other general topics but those three stood > out for me. > > Oh, and there's this: > >> 2.13. Security tools impact comparison >> >> From Brian Carpenter. For further discussion. > > Not quite sure what I had in mind there. What I wrote (in > off-list mail) was "There's also the question of how the > approaches relate to APAM tools and to security tools." > I can see that there might be interaction with APAM. Maybe > there needs to be interaction with address-based security > settings? Hm. Not sure :-) Anyway, the practical choice today really is one of the two: 1) RA-only 2) RA+DHCP I think I heard fairly distinct objections against even thinking about touching this. Even if I also heard a distinct dissatisfaction with this state of affairs, unless there's a consensus to think of changing it, we have what we have. Thus if we assume this status quo + the MUST / SHOULD designations in hosts requirements, I'd put a decision tree a potential implementer as follows: 1) Are you configuring an application ? If yes - avoid RA and DHCP altogether, do something else. If you are configuring an INTAREA protocol, continue to (2). 2) Do you have a very very very good reason to use DHCPv6 as a carrier for your configuration info, even bearing in mind that not all nodes may support it (or the subset of nodes of interest ? Then use DHCPv6. 3) Use RA. The draft then is indeed aiming at the protocol implementors aiming to answer the (2), the abstract needs to be sharpened to reflect that, and indeed a much better place for it would be (eventually) 6man (with the help of dhc, of course). Therefore: I solicit those who are interested to further work on this doc to unicast me, so we can free up the carrier in v6ops. --a From alexandru.petrescu@gmail.com Tue Dec 17 10:02:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD61AE0A3 for ; Tue, 17 Dec 2013 10:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_24=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2vKIXb2YVtD for ; Tue, 17 Dec 2013 10:02:09 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 491E61AE1C0 for ; Tue, 17 Dec 2013 10:02:09 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBHHwrIi016783; Tue, 17 Dec 2013 18:58:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E56EE208016; Tue, 17 Dec 2013 18:59:19 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D7FA0207F8B; Tue, 17 Dec 2013 18:59:19 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBHHwqS1008180; Tue, 17 Dec 2013 18:58:52 +0100 Message-ID: <52B090DC.7000304@gmail.com> Date: Tue, 17 Dec 2013 18:58:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andrew Yourtchenko , Brian E Carpenter References: <20131127125213.17409.86382.idtracker@ietfa.amsl.com> <52AF9FAB.7060702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-yourtchenko-ra-dhcpv6-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 18:02:11 -0000 Le 17/12/2013 12:12, Andrew Yourtchenko a écrit : > Hi, > > On Tue, 17 Dec 2013, Brian E Carpenter wrote: > >> Hi, >> >> (Still on v6ops, although 6man might be appropriate.) >> > > yep. See my comment at the end. > >> I think that there are some topics quite deep inside the draft that >> really belong nearer the beginning. After all, these are the issues >> that will guide future work: do we add feature X to RA, DHCPv6, or >> both?. >> >> In a logical order, these topics are: >> >> a) 4. Differences between different types of network operators >> >> b) 2.11. Scope of use / Applicability (e.g. 2.7. Involvement or not >> into routing) (e.g. to what extent do we want feature-equivalence >> and a shared data model?) >> >> c) 2.10. Separate vs. unified management >> >> There may be other general topics but those three stood out for >> me. >> >> Oh, and there's this: >> >>> 2.13. Security tools impact comparison >>> >>> From Brian Carpenter. For further discussion. >> >> Not quite sure what I had in mind there. What I wrote (in off-list >> mail) was "There's also the question of how the approaches relate >> to APAM tools and to security tools." I can see that there might be >> interaction with APAM. Maybe there needs to be interaction with >> address-based security settings? > > Hm. Not sure :-) > > Anyway, the practical choice today really is one of the two: > > 1) RA-only 2) RA+DHCP > > I think I heard fairly distinct objections against even thinking > about touching this. Even if I also heard a distinct dissatisfaction > with this state of affairs, unless there's a consensus to think of > changing it, we have what we have. > > Thus if we assume this status quo + the MUST / SHOULD designations in > hosts requirements, I'd put a decision tree a potential implementer > as follows: > > 1) Are you configuring an application ? If yes - avoid RA and DHCP > altogether, do something else. If you are configuring an INTAREA > protocol, continue to (2). > > 2) Do you have a very very very good reason to use DHCPv6 as a > carrier for your configuration info, even bearing in mind that not > all nodes may support it (or the subset of nodes of interest ? Then > use DHCPv6. > > 3) Use RA. > > The draft then is indeed aiming at the protocol implementors aiming > to answer the (2), the abstract needs to be sharpened to reflect > that, and indeed a much better place for it would be (eventually) > 6man (with the help of dhc, of course). > > Therefore: I solicit those who are interested to further work on this > doc to unicast me, so we can free up the carrier in v6ops. But in this email one seems to be suggesting a big recommendation DHCP vs RA, whereas something smaller and less contentious would be - among other things - a description of parameters configured by DHCP vs parameters configured by RA. Alex > > --a _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From brian.e.carpenter@gmail.com Tue Dec 17 11:36:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD621A8028 for ; Tue, 17 Dec 2013 11:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH_Ci0il-j31 for ; Tue, 17 Dec 2013 11:36:39 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 352E61A1F4A for ; Tue, 17 Dec 2013 11:36:39 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id lj1so4942846pab.1 for ; Tue, 17 Dec 2013 11:36:38 -0800 (PST) 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=TGP8QWKgzS8k/CZ5F/EHunazza14YOYFG4RA5yk10MU=; b=LrE3v+RDUoKcI9HVzd1918jqS/iqZM35VQ46mbIa3r/WQoPIodW2DnBrqXTNktiWvY 2MeRsFMsXlCsb9xXBZMHCG1aCWc7Y/LVZy2cg2Bv6XIJirSnzDVsVL2ry+nGUsjGDGlN rfPA4KSY7oIvHEa/qPwygQ9GD4XJxtWRoFlFW4gBiw04Cv4sKgRnpgz0S9Ez5ZQCxIWN Zcqp0TvjHfh6KokxIwr7p9hIyjoZFqni4ciSHi0Cm6JJ3rtfVV6b0+cEp/2Y9c2E7KcN XxmHw+HMC32cxOIq4Xv8aqEcnANXoNIAHYHdbSYXD/RYeTM4qX6hpnajXUEoIcyXpcDw s66Q== X-Received: by 10.68.238.226 with SMTP id vn2mr28503270pbc.50.1387308998127; Tue, 17 Dec 2013 11:36:38 -0800 (PST) Received: from [192.168.178.20] (220.194.69.111.dynamic.snap.net.nz. [111.69.194.220]) by mx.google.com with ESMTPSA id lh13sm48452722pab.4.2013.12.17.11.36.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Dec 2013 11:36:37 -0800 (PST) Message-ID: <52B0A7C6.60506@gmail.com> Date: Wed, 18 Dec 2013 08:36:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 19:36:41 -0000 On 17/12/2013 21:27, Lorenzo Colitti wrote: > On Tue, Dec 17, 2013 at 4:57 PM, Liubing (Leo) = wrote: >=20 >> If a DHCPv6-only scenario is presented, then it needs to be stated >> that the nodes will not have any off-link connectivity, and thus that = this >> scenario is possibly of limited use. >> >> [Bing] Isolated network is indeed a valid use case, thanks Ted for >> mentioning this. However, the whole motivation for inventing the SLAAC and RA mechanism was for zeroconf networks (which we often called "Dentist's Office networ= ks" to suggest the use case). I can't prove it with archived email, but I'm pretty sure that somebody said "and then we certainly won't need DHCP for IPv6". So I can equally well argue that an isolated network is the perfect use case for SLAAC/RA. >> >=20 > Do you really want to mention this as a use case? What's the point of > setting up a DHCPv6 server if the addresses it assigns can't talk to > anything off-link anyway? Exactly. It is a solution searching for a problem. Brian >=20 > If you do insist on mentioning it, please make it very clear that such = a > use case does not permit any sort of communication outside the link (no= t > "outside the network" - "outside the link"), and that the you don't nee= d to > configure a DHCPv6 server to do that - you can just use link-local > addresses, which are created automatically. >=20 >=20 >> Regardless of specific use cases, for the behavior =E2=80=9CRA is re= quired for >> initialing DHCPv6=E2=80=9D, I think: >> >> 1. The dependency is not quite reasonable; >> >=20 > I don't think it's unreasonable, because an RA is needed for connectivi= ty > anyway. Also, if there is no IPv6 off-link connectivity but there is IP= v4 > off-link connectivity, then it's better for hosts *not* to have an IPv6= > address. This is because if they do have an IPv6 address, then they wil= l > waste their time doing AAAA lookups for off-link destinations which the= y > can't reach. >=20 >=20 >> 2. Whether there should be dependency is ambiguous in standard, and = it >> is why current implementations have varied on this issue (some will >> initiate DHCPv6 if no RA; some just do nothing). >> >=20 > I don't think this is a big problem, since if there is no router there'= s no > off-link connectivity, and a network without off-link connectivity is n= ot > very useful. >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Tue Dec 17 12:23:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A871ACCE0 for ; Tue, 17 Dec 2013 12:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea6fuQKiJoql for ; Tue, 17 Dec 2013 12:23:24 -0800 (PST) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 743D11ACCDC for ; Tue, 17 Dec 2013 12:23:24 -0800 (PST) Received: from [66.196.81.174] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 17 Dec 2013 20:23:23 -0000 Received: from [98.139.212.206] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 17 Dec 2013 20:23:23 -0000 Received: from [127.0.0.1] by omp1015.mail.bf1.yahoo.com with NNFMP; 17 Dec 2013 20:23:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 189727.6730.bm@omp1015.mail.bf1.yahoo.com Received: (qmail 73895 invoked by uid 60001); 17 Dec 2013 20:23:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1387311802; bh=U8Vqt0A2WHCzov2LwRysW+Ad2M2SrA4Oexb0GGxAABM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kRiHjEvxwPUuKr5zxLI/lfFBoDzud+zjc9aeUomX7goIQk0n2fADvlM/8hqSXoIOaY4rDkSAYRNJZNj7m+S8ySALqSq20L7AYYuViVvbGpnKCQ/irT0tLtxZN63LSuyOwxWCcS/z8QPnJSKwnozTUZVNUe1nHrAngA4pISE1fR0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iJBdhkqjT7mg8L8uSfvhsJPb0DnKWVeG1l1Mt7I9y0ocQhtAGj3jeeLTx/ZlbN3AeYb0WRJnNXq+Zx1hJZp99fRDagCVce74SILOef8gs4O43BDpMJju/2tu1saBXLUV+KM/4JYyVCuBl0sRa+5AjcmURLY/+6YmZNc2SnxK5Ag=; X-YMail-OSG: Yezf18EVM1ml_OGjF7CeWkPFYSOgBOQTw2bo18O6ai_3e0Y gahu4UXcXeeJlprs8hsf70QdTcgbyCptk200vOOROcl3jYEEmAJgNSbCiHBt f0jlG_.pzkvm2vUM5QPnijDZLGAh_Du42hHvPTPXKPQXTMJApodlwg6THnw8 OEOsygWuydG.7gq9s7Y7BkjNad_P6MZIDl6oLiz3t._0MBthInMFtmOkMMBn vRadDbjNgD1i1Lis7JF85IJYKHs9VJeS5f_C27dqNHIp8OeVt1iCprbqTc4K 7WRZW3aAw_FjTFqZQpCaKt_jMWrGi3g004qJbcHR05RMkYd_CCfrlXvGu0Yx mOl5xHXoP_uCF9Y9hdPLwbiQl.jeDFFV2zCoI77QCxCmKLCFJTXjFxRCBnb6 3q0kRPgzFY6D6FGlq9LhpsaJt88weZfErMT2Xqi4PL9zQThEVtu04f3czj1b 89j7J4jnaePjQS9ZGupAYtEth8vke9bkQhHQaKsZbnarTxFJc_r7nyjBferp 2grVTxpVltN1kSUnyPr_vj8wgel7fnRCZaEkutSLOaqVadQTaKv2xFivAiQM 0M_L7r9DiiBsOcAgxY2Cv Received: from [150.101.221.237] by web161902.mail.bf1.yahoo.com via HTTP; Tue, 17 Dec 2013 12:23:22 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPiBDYzogInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc.Cj4gU2VudDogV2VkbmVzZGF5LCAxOCBEZWNlbWJlciAyMDEzIDY6MzYgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.170.612 References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <52B0A7C6.60506@gmail.com> Message-ID: <1387311802.16950.YahooMailNeo@web161902.mail.bf1.yahoo.com> Date: Tue, 17 Dec 2013 12:23:22 -0800 (PST) From: Mark ZZZ Smith To: Brian E Carpenter , Lorenzo Colitti In-Reply-To: <52B0A7C6.60506@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 20:23:25 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Lorenzo Colitti =0A> Cc= : "v6ops@ietf.org WG" =0A> Sent: Wednesday, 18 December 201= 3 6:36 AM=0A> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac= -problem=0A> =0A> On 17/12/2013 21:27, Lorenzo Colitti wrote:=0A>> On Tue,= Dec 17, 2013 at 4:57 PM, Liubing (Leo) =0A> wrote:= =0A>> =0A>>> =C2=A0 =C2=A0 If a DHCPv6-only scenario is presented, then it = needs to be stated=0A>>> that the nodes will not have any off-link connect= ivity, and thus that =0A> this=0A>>> scenario is possibly of limited use.= =0A>>> =0A>>> [Bing] Isolated network is indeed a valid use case, thanks T= ed for=0A>>> mentioning this.=0A> =0A> However, the whole motivation for i= nventing the SLAAC and RA mechanism=0A> was for zeroconf networks (which we= often called "Dentist's Office =0A> networks"=0A> to suggest the use case)= . I can't prove it with archived email, but=0A> I'm pretty sure that somebo= dy said "and then we certainly won't =0A> need=0A> DHCP for IPv6".=0A>=C2= =A0=0A=0ASo I recently remembered reading something about IPv4 ICMP based d= efault gateway discovery a long time ago and decided to look up more detail= s.=0A=0AIPv4 RAs are actually older than DHCPv4 as we know it by two years = (the RFC editor explains why it is in IPv6)=0A=0ARFC1256, "ICMP Router Disc= overy Messages." S. Deering, Ed.. September 1991.=0A=0ARFC1531, "Dynamic Ho= st Configuration Protocol."=C2=A0R. Droms. October 1993.=0A=0AI also found = that my Fedora 19 host had the client installed by default (rdisc), and als= o found that both Cisco and Juniper have implementations of the server avai= lable on their router platforms.=0A=0AIPv4 RAs don't have a prefix informat= ion option so hosts had to acquire prefix/host address information some oth= er way. If hosts were able to dynamically acquire that information, then Ap= pletalk has demonstrated that it isn't necessary to have large host address= space to be able to have hosts dynamically generate their own addresses an= d check them for validity.=0A=0A=0A> So I can equally well argue that an is= olated network is the perfect=0A> use case for SLAAC/RA.=0A> =0A>>> =0A>> = =0A>> Do you really want to mention this as a use case? What's the point o= f=0A>> setting up a DHCPv6 server if the addresses it assigns can't talk t= o=0A>> anything off-link anyway?=0A> =0A> Exactly. It is a solution search= ing for a problem.=0A>=C2=A0=0A=0AThat specific scenario is my understandin= g of the reason for the existence of link-local addressing, and why they ar= e candidate addresses for use by applications in the address selection RFC = and instructions on how they work with/are to be used by applications are p= rovided in RFC4007.=0A=0AUbiquitous "link-local" addressing ensures that yo= u don't need an external source of layer 3 addressing information for the n= odes to locally communicate. It also isn't a new idea, IPv4 originally had = 'this network' - the network portion of the address of all zeros (which sub= sequently might have been reinvented as 169.254/16 for the same purpose), I= PX had network 0x000000, and Appletalk had cable range 0xff00 through 0xfff= e.=0A=0A=0A=0ARegards,=0AMark.=0A=0A> =C2=A0 Brian=0A> =0A>> =0A>> If you= do insist on mentioning it, please make it very clear that such a=0A>> us= e case does not permit any sort of communication outside the link (not=0A>>= "outside the network" - "outside the link"), and that =0A> the you don't = need to=0A>> configure a DHCPv6 server to do that - you can just use link-= local=0A>> addresses, which are created automatically.=0A>> =0A>> =0A>>> = =C2=A0 Regardless of specific use cases, for the behavior =E2=80=9CRA is r= equired =0A> for=0A>>> initialing DHCPv6=E2=80=9D, I think:=0A>>> =0A>>> = 1. The dependency is not quite reasonable;=0A>>> =0A>> =0A>> I don't think= it's unreasonable, because an RA is needed for =0A> connectivity=0A>> any= way. Also, if there is no IPv6 off-link connectivity but there is IPv4=0A>>= off-link connectivity, then it's better for hosts *not* to have an IPv6= =0A>> address. This is because if they do have an IPv6 address, then they = will=0A>> waste their time doing AAAA lookups for off-link destinations wh= ich they=0A>> can't reach.=0A>> =0A>> =0A>>> =C2=A0 2. Whether there shou= ld be dependency is ambiguous in standard, and =0A> it=0A>>> is why curren= t implementations have varied on this issue (some will=0A>>> initiate DHCP= v6 if no RA; some just do nothing).=0A>>> =0A>> =0A>> I don't think this i= s a big problem, since if there is no router =0A> there's no=0A>> off-link= connectivity, and a network without off-link connectivity is not=0A>> ver= y useful.=0A>> =0A>> =0A>> =0A>> -----------------------------------------= -------------------------------=0A>> =0A>> _______________________________= ________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https:= //www.ietf.org/mailman/listinfo/v6ops=0A> =0A> =0A> _______________________= ________________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> http= s://www.ietf.org/mailman/listinfo/v6ops=0A> From leo.liubing@huawei.com Tue Dec 17 18:06:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43331AE1C6 for ; Tue, 17 Dec 2013 18:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDTiQxgRq7Vx for ; Tue, 17 Dec 2013 18:06:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9AE71AE152 for ; Tue, 17 Dec 2013 18:06:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZC75610; Wed, 18 Dec 2013 02:06:10 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 02:05:42 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 02:06:09 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 10:06:02 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO8PcjWuMJf8I9f0eBAQAUd5rlEZpWADIAgAGs+wD//5YhgIAAht9g//+EgICAAAOWgIAAAQAAgACsAXD//5xtAAAS/iZA//+J64D//nybwA== Date: Wed, 18 Dec 2013 02:06:01 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D825F6D@nkgeml506-mbx.china.huawei.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825F6Dnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 02:06:16 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825F6Dnkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMTcsIDIwMTMgNjoyOSBQTQ0KVG86IExpdWJpbmcgKExlbykNCkNj OiBUZWQgTGVtb247IHY2b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcg ZHJhZnQ6IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0NCg0KT24gVHVlLCBE ZWMgMTcsIDIwMTMgYXQgNzowMyBQTSwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2Vp LmNvbTxtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KRG8geW91IHJlYWxs eSB3YW50IHRvIG1lbnRpb24gdGhpcyBhcyBhIHVzZSBjYXNlPw0KW0JpbmddIFllcy4NCg0KV2hh dCdzIHRoZSBwb2ludCBvZiBzZXR0aW5nIHVwIGEgREhDUHY2IHNlcnZlciBpZiB0aGUgYWRkcmVz c2VzIGl0IGFzc2lnbnMgY2FuJ3QgdGFsayB0byBhbnl0aGluZyBvZmYtbGluayBhbnl3YXk/DQpb QmluZ10gSXQgbWlnaHQgYmUgbm9uc2Vuc2UgZm9yIHlvdSwgYnV0IHlvdSBuZXZlciBrbm93IHdo byBtaWdodCBuZWVkIHRoaXMgdXNlIGNhc2UuIEFuZCBmb3IgdGhpcyBkb2N1bWVudCwgaXQgaXMg bm90IGEgZ29hbCB0byBqdWRnZSB0aGUgdXNlIGNhc2UgdmFsaWQgb3Igbm90LCBidXQgdG8gcHJv dmlkZSBjYXV0aW9ucyB0aGF0IHRoZXJlIG1pZ2h0IGJlIHByb2JsZW0gaW4gdGhlc2Ugb3IgdGhv c2UgY2FzZXMuDQoNCkkgdGhpbmsgVG9yZSdzIGNvbW1lbnQgbWFrZXMgaXQgY2xlYXIgdGhhdCB0 aG9zZSBhZGRyZXNzZXMgd29uJ3Qgd29yayAqYXQgYWxsKiwgbm90IGV2ZW4gZm9yIG9uLWxpbmsg Y29tbXVuaWNhdGlvbi4gSSBzdHJvbmdseSBvYmplY3QgdG8gbGlzdGluZyBhIHVzZSBjYXNlIHRo YXQgYXNzaWducyBhZGRyZXNzZXMgdGhhdCBkb24ndCB3b3JrLg0KW0JpbmddIE15IHByZXZpb3Vz IGFyZ3VtZW50IGFib3ZlIHdhcyBhc3N1bWluZyB0aGUgdXNlIGNhc2Ugd29ya3MsIGJ1dCBzb21l b25lIG1pZ2h0IGRvbuKAmXQgcHJlZmVyIHRvIHVzZSBpdC4gVGhlbiBpdCBpcyBub3Qgb3VyIGdv YWwgdG8ganVkZ2UgdGhlIGNhc2UgZ29vZCBvciBub3QuDQpCdXQgaWYgaXQgZG9lc27igJl0IHdv cmsgYXQgYWxsLCB0aGVuIEkgYWdyZWUgd2l0aCB5b3UgaXQgc2hvdWxkIG5vdCBiZSBsaXN0ZWQs IG9yIG1ha2UgYSBjbGVhciBzdGF0ZW1lbnQgdGhlIGNhc2UgaXMgbm90IGFwcGxpY2FibGUuDQoN ClRoYW5rIHlvdS4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825F6Dnkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMb3JlbnpvIENvbGl0dGkg W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RGVjZW1iZXIgMTcsIDIwMTMgNjoyOSBQTTxicj4NCjxiPlRvOjwvYj4gTGl1YmluZyAoTGVvKTxi cj4NCjxiPkNjOjwvYj4gVGVkIExlbW9uOyB2Nm9wc0BpZXRmLm9yZyBXRzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNs YWFjLXByb2JsZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBUdWUsIERlYyAxNywgMjAxMyBhdCA3OjAzIFBNLCBMaXViaW5nIChMZW8p ICZsdDs8YSBocmVmPSJtYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmxlby5saXViaW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM1MDAwNTAiPkRvIHlvdSByZWFsbHkgd2FudCB0byBtZW50 aW9uIHRoaXMgYXMgYSB1c2UgY2FzZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBZZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCdzIHRoZSBwb2lu dCBvZiBzZXR0aW5nIHVwIGEgREhDUHY2IHNlcnZlciBpZiB0aGUgYWRkcmVzc2VzIGl0IGFzc2ln bnMgY2FuJ3QgdGFsayB0byBhbnl0aGluZyBvZmYtbGluayBhbnl3YXk/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JpbmddIEl0IG1pZ2h0IGJl IG5vbnNlbnNlIGZvciB5b3UsIGJ1dCB5b3UgbmV2ZXIga25vdyB3aG8gbWlnaHQgbmVlZCB0aGlz IHVzZSBjYXNlLg0KIEFuZCBmb3IgdGhpcyBkb2N1bWVudCwgaXQgaXMgbm90IGEgZ29hbCB0byBq dWRnZSB0aGUgdXNlIGNhc2UgdmFsaWQgb3Igbm90LCBidXQgdG8gcHJvdmlkZSBjYXV0aW9ucyB0 aGF0IHRoZXJlIG1pZ2h0IGJlIHByb2JsZW0gaW4gdGhlc2Ugb3IgdGhvc2UgY2FzZXMuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkkgdGhpbmsgVG9yZSdzIGNvbW1lbnQgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aG9zZSBhZGRy ZXNzZXMgd29uJ3Qgd29yayAqYXQgYWxsKiwgbm90IGV2ZW4gZm9yIG9uLWxpbmsgY29tbXVuaWNh dGlvbi4gSSBzdHJvbmdseSBvYmplY3QgdG8gbGlzdGluZyBhIHVzZSBjYXNlIHRoYXQgYXNzaWdu cyBhZGRyZXNzZXMgdGhhdCBkb24ndCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W0JpbmddIE15IHByZXZpb3VzIGFyZ3VtZW50IGFib3ZlIHdhcyBhc3N1 bWluZyB0aGUgdXNlIGNhc2Ugd29ya3MsIGJ1dCBzb21lb25lIG1pZ2h0IGRvbuKAmXQgcHJlZmVy IHRvIHVzZSBpdC4gVGhlbiBpdCBpcyBub3Qgb3VyIGdvYWwgdG8ganVkZ2UgdGhlDQogY2FzZSBn b29kIG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1 dCBpZiBpdCBkb2VzbuKAmXQgd29yayBhdCBhbGwsIHRoZW4gSSBhZ3JlZSB3aXRoIHlvdSBpdCBz aG91bGQgbm90IGJlIGxpc3RlZCwgb3IgbWFrZSBhIGNsZWFyIHN0YXRlbWVudCB0aGUgY2FzZSBp cyBub3QgYXBwbGljYWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CaW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D825F6Dnkgeml506mbxchi_-- From internet-drafts@ietf.org Tue Dec 17 21:01:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D2E1AD73E; Tue, 17 Dec 2013 21:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS0WS1qBmfW6; Tue, 17 Dec 2013 21:00:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE151ADF5C; Tue, 17 Dec 2013 21:00:57 -0800 (PST) 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 X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131218050057.32441.78032.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2013 21:00:57 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 05:01:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experience Author(s) : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-06.txt Pages : 22 Date : 2013-12-17 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From phdgang@gmail.com Tue Dec 17 21:07:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3311ADFB0 for ; Tue, 17 Dec 2013 21:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Tay2LXm97c for ; Tue, 17 Dec 2013 21:07:45 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 371E91ADED6 for ; Tue, 17 Dec 2013 21:07:45 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id e16so5710386qcx.17 for ; Tue, 17 Dec 2013 21:07:43 -0800 (PST) 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 :content-type; bh=mB4LnuDgoHeryxUoKQtEF26rzPo0KOHG5xFfhfOeq+Q=; b=SP0eFqmTUw5N7zyNgjGVavpHK0Tn/oMoCHcHYr257Y190kcelEvK4fwYPtMy++IK1n NXQ7POgYza5Qf04V67J09Hckip/OvWDC342TAYgWspe6+vM1CenoljtZU3/DSYsNvHqV bGEjmDHovtUey4OHzGc1y0dJ4v9p5u5Vb8l219Uzn7dYKySrhPZQCtJEHrv6bAxB0Qoh SwcT8DN/ZlME2KapzEezFGMkMBdAyS6RJWJz6DLcnumKs2953coBL7Fjzwcf9FjG58hT OyaBnSE27Q1gzxebGVtrRGToEZfrPt67cGX89SrtbjWPOJwe9H0NtGvod3VLVQL88ByB ek8A== MIME-Version: 1.0 X-Received: by 10.224.111.195 with SMTP id t3mr49685268qap.98.1387343263781; Tue, 17 Dec 2013 21:07:43 -0800 (PST) Received: by 10.224.172.135 with HTTP; Tue, 17 Dec 2013 21:07:43 -0800 (PST) In-Reply-To: <20131218050057.32441.78032.idtracker@ietfa.amsl.com> References: <20131218050057.32441.78032.idtracker@ietfa.amsl.com> Date: Wed, 18 Dec 2013 13:07:43 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 05:07:47 -0000 Wg, We have made another updates according to the discussions within the week. Please kindly check/review BRs Gang 2013/12/18, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : NAT64 Operational Experience > Author(s) : Gang Chen > Zhen Cao > Chongfeng Xie > David Binet > Filename : draft-ietf-v6ops-nat64-experience-06.txt > Pages : 22 > Date : 2013-12-17 > > Abstract: > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and > NAT64 server Front End (NAT64-FE) are considered in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Ted.Lemon@nominum.com Wed Dec 18 05:13:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5F01AE1E5 for ; Wed, 18 Dec 2013 05:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39VqtAewrR_3 for ; Wed, 18 Dec 2013 05:13:27 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD741AE3DC for ; Wed, 18 Dec 2013 05:13:27 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUrGfdo+o7vW9aFt2fXpT6ColJjBMXpId@postini.com; Wed, 18 Dec 2013 05:13:26 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 293FD1B82E2 for ; Wed, 18 Dec 2013 05:13:26 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id F2E8C190043; Wed, 18 Dec 2013 05:13:25 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 05:13:26 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D825F6D@nkgeml506-mbx.china.huawei.com> Date: Wed, 18 Dec 2013 08:13:25 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <3B20F72A-F79B-4F1B-88E2-D0B1F7A48DB6@nominum.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825F6D@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 13:13:29 -0000 On Dec 17, 2013, at 9:06 PM, Liubing (Leo) = wrote: > [Bing] My previous argument above was assuming the use case works, but = someone might don=92t prefer to use it. Then it is not our goal to judge = the case good or not. > But if it doesn=92t work at all, then I agree with you it should not = be listed, or make a clear statement the case is not applicable. Does IPv6 bonjour not work on a local wire without router = advertisements? From ayourtch@cisco.com Wed Dec 18 05:20:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB41AE3C8 for ; Wed, 18 Dec 2013 05:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QCgZYKV55Of for ; Wed, 18 Dec 2013 05:20:32 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 87D951AE17C for ; Wed, 18 Dec 2013 05:20:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBIDKUk1017252 for ; Wed, 18 Dec 2013 14:20:30 +0100 (CET) Received: from ams3-vpn-dhcp2462.cisco.com (ams3-vpn-dhcp2462.cisco.com [10.61.73.158]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBIDKQBk006727; Wed, 18 Dec 2013 14:20:27 +0100 (CET) Date: Wed, 18 Dec 2013 13:20:23 +0000 (WET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Alexandru Petrescu In-Reply-To: <52B090DC.7000304@gmail.com> Message-ID: References: <20131127125213.17409.86382.idtracker@ietfa.amsl.com> <52AF9FAB.7060702@gmail.com> <52B090DC.7000304@gmail.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-yourtchenko-ra-dhcpv6-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 13:20:36 -0000 On Tue, 17 Dec 2013, Alexandru Petrescu wrote: > But in this email one seems to be suggesting a big recommendation DHCP > vs RA, whereas something smaller and less contentious would be - among > other things - a description of parameters configured by DHCP vs > parameters configured by RA. I think that's how it started... (from my email attempting to specify the properties of DHCP vs. RA in order to be able to easier choose DHCP vs. RA). I suppose having an appendix with "what is configured today via DHCP and what is configured via RA" is ok. --a From lorenzo@google.com Wed Dec 18 05:43:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826761AE3C8 for ; Wed, 18 Dec 2013 05:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgqkxlZEQARl for ; Wed, 18 Dec 2013 05:43:54 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 18C171AE400 for ; Wed, 18 Dec 2013 05:43:53 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id uq1so1129128igb.1 for ; Wed, 18 Dec 2013 05:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KNX7ZkM0rf/l8V8Xlu4xfQxzCyf2zguzHlLk5lOFLo4=; b=HiYmnwxjq9MQTqn/IrghCk9u2HLM2L0GgKqggVjjdrBwB1Tc5Ck/iGloGr3hiqYUEd KZZI5W4x3uJ1N3ApNTd/upqvRTiEaeCFhl2wRnwYAO3jWsFcaImS9v35+COA8GP4rwQv o18y56VaVGGbrT9l56i8W/e23p8b960q9+EM+nESOaLz/uXe2KevPawmiMq9/taZfr9f ARuZ5XBbz3SxJ/rKhgUhKAfTLmyk3Y/UKXzxJluZNdQRRR4Mp+nYWYs5pvM8Ga3/pms0 Y+tz4Gjg0oOpi8pbyeEnu/N9ExUx21ThYEbtfaJE+0ObL4F1Oe+Zq/qeMcU2uYvdJ+Hy ElpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KNX7ZkM0rf/l8V8Xlu4xfQxzCyf2zguzHlLk5lOFLo4=; b=YJbAHe2TeSnp7i87aKN8hJHCu0Nd6bUHpZjvX/GtfVgeLkuCvVkz4kBcBzBXHarsca 9No1HGXcO6+pnsxim1qRPIrYNmEG5rN4HpQvm7Z5IbN9t1Um50KE1RIOZlTX8tLkZq2F oezV/lbOOkUYj1Sc8+/wn3N2TV8qxL2jktgW9ZB7xY5+1ai23XWicKiJrEFxqR9whWaj teMLU5BwEUhOpfTmBFh/1RIqJFKVGz2Wr1XVYM14RCJedgVCtsANmgGwUD39UQ2oyJw7 x9OiwlaE6uu0o3gjFeOvrdL1NBfT1x7OGMgXFa2WCZo7PI6iKay1/W1oErMwY4W89l0r 7blg== X-Gm-Message-State: ALoCoQlIxmVBDYcVG8RtltPcg4mj3KWa4gB1r3TSBU5shqhe6RIDto6W3KmWeVk1EK240OP7QIn2lVavazSbwFUVtN/vc2hGu2gn5uyy62fgPFHcXjzWRyzJJpcxLdcEN0cnEFqLsOOo/410X4gWHjFo/Vpv2O9qQn1bBaZoS8B0lMfFAGt/VfpNPxQJi0rzwT4uFNYC0i/r X-Received: by 10.50.55.106 with SMTP id r10mr8050324igp.45.1387374232433; Wed, 18 Dec 2013 05:43:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 18 Dec 2013 05:43:32 -0800 (PST) In-Reply-To: <3B20F72A-F79B-4F1B-88E2-D0B1F7A48DB6@nominum.com> References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825F6D@nkgeml506-mbx.china.huawei.com> <3B20F72A-F79B-4F1B-88E2-D0B1F7A48DB6@nominum.com> From: Lorenzo Colitti Date: Wed, 18 Dec 2013 22:43:32 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b10ce434bb25c04edcf3cfb Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 13:43:55 -0000 --047d7b10ce434bb25c04edcf3cfb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 18, 2013 at 10:13 PM, Ted Lemon wrote: > > [Bing] My previous argument above was assuming the use case works, but > someone might don=E2=80=99t prefer to use it. Then it is not our goal to = judge the > case good or not. > > But if it doesn=E2=80=99t work at all, then I agree with you it should = not be > listed, or make a clear statement the case is not applicable. > > Does IPv6 bonjour not work on a local wire without router advertisements? > Yes, but it works with link-local addresses, so it doesn't need DHCPv6 either. As Tore notes, per spec getting an IPv6 address via DHCPv6 is not sufficient to talk to anyone at all, period. This is because there's no way to guess the prefix size assigned to the link, and so no way to create a routing table entry that allows you to send packets. Stacks used to assume that everything is on link, but that was reversed by RFC 4943. --047d7b10ce434bb25c04edcf3cfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 18, 2013 at 10:13 PM, Ted Lemon <ted.lemon@nominum.com>= wrote:
> [Bing] My previous ar= gument above was assuming the use case works, but someone might don=E2=80= =99t prefer to use it. Then it is not our goal to judge the case good or no= t.
> But if it doesn=E2=80=99t work at all, then I agree with you it should= not be listed, or make a clear statement the case is not applicable.

Does IPv6 bonjour not work on a local wire without router advertiseme= nts?

Yes, but it works with link-local = addresses, so it doesn't need DHCPv6 either.

As Tore notes, per spec getting an IPv6 address via DHCPv6 is not sufficien= t to talk to anyone at all, period. This is because there's no way to g= uess the prefix size assigned to the link, and so no way to create a routin= g table entry that allows you to send packets. Stacks used to assume that e= verything is on link, but that was reversed by RFC 4943.
--047d7b10ce434bb25c04edcf3cfb-- From rja.lists@gmail.com Wed Dec 18 07:27:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D6A1AE1DF for ; Wed, 18 Dec 2013 07:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjjqnKbPf-GT for ; Wed, 18 Dec 2013 07:27:04 -0800 (PST) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC71AE189 for ; Wed, 18 Dec 2013 07:27:04 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id cy11so6632777qeb.13 for ; Wed, 18 Dec 2013 07:27:02 -0800 (PST) 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 :to:mime-version; bh=z7oL2HmsGMwL1qwp1zWaFAVEtMU1ufMsVo8SHlAOo24=; b=WPfz4S0xUsS1oE9Xhd0vFuQZFlCSbnrERih96+EpBm3MR4L36y0oIV9Y44KGxM8i1D uNhEbT0vzuShJcb4m5zwV46S7yrQeVjI5k6vE54WyFaKlgWDKzSDYyeqjXYCaA17rLq1 ze4Nd7vj9AEl/KsHCbKtgg3LFbzGtWDWuC0Hr6njt/8e0uiqXlL2LxiiQtrzKHG/6HgO N12jBQSlOkqqZUvnPF+pFKzTIP9zv99XWbfcuPiw1P/wiy2YMipNjd9kh2NBeHk5IW6c N/J1/R3+guZwF8y7+ms56HwG989GrVugqI065rEVhXKEDt2b/1t1fZ9/r7r76pSonPHJ 7+7g== X-Received: by 10.49.14.3 with SMTP id l3mr54337855qec.67.1387380422692; Wed, 18 Dec 2013 07:27:02 -0800 (PST) Received: from [10.30.20.11] (pool-108-56-248-238.washdc.fios.verizon.net. [108.56.248.238]) by mx.google.com with ESMTPSA id f19sm888102qaq.12.2013.12.18.07.27.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Dec 2013 07:27:02 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Dec 2013 10:27:07 -0500 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 15:27:06 -0000 On Weds, 18 Dec 2013 @ 08:36:38 +1300, Brian E Carpenter wrote: > However, the whole motivation for inventing the SLAAC and RA > mechanism was for zeroconf networks (which we often called > "Dentist's Office networks" to suggest the use case). This also is my recollection. > I can't prove it with archived email, but I'm pretty sure that > somebody said "and then we certainly won't need DHCP for IPv6". This also is my recollection. > So I can equally well argue that an isolated network is the > perfect use case for SLAAC/RA. Agreed. Among the reasons to prefer SLAAC/RA over DHCPv6 in an isolated (or otherwise unmanaged) network is to eliminate the need to purchase, deploy, configure, and operate extraneous servers (such as a DHCP Server). The subsequent widespread deployment of mDNS and DNS-SD also has been beneficial in eliminating the need for other extraneous servers (e.g. DNS) in an isolated network, furthering the goal of "Zero Configuration Networking". > Exactly. It is a solution searching for a problem. I fully agree. Yours, Ran Atkinson From alexandru.petrescu@gmail.com Wed Dec 18 08:46:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FFE1AE1B1 for ; Wed, 18 Dec 2013 08:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM1eP65K9rXX for ; Wed, 18 Dec 2013 08:46:19 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1631AE19F for ; Wed, 18 Dec 2013 08:46:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBIGkGhE019210; Wed, 18 Dec 2013 17:46:16 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88D0F2084D0; Wed, 18 Dec 2013 17:46:44 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7AE8220206A; Wed, 18 Dec 2013 17:46:44 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBIGkCQ4026165; Wed, 18 Dec 2013 17:46:16 +0100 Message-ID: <52B1D154.7050405@gmail.com> Date: Wed, 18 Dec 2013 17:46:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti , Ted Lemon References: <201312041345.rB4Dj1O12856@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CA0@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825CD1@nkgeml506-mbx.china.huawei.com> <5F837C86-57D9-4C7F-B184-9031C1261558@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825D62@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825DD8@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D825F6D@nkgeml506-mbx.china.huawei.com> <3B20F72A-F79B-4F1B-88E2-D0B1F7A48DB6@nominum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 16:46:21 -0000 Le 18/12/2013 14:43, Lorenzo Colitti a écrit : > On Wed, Dec 18, 2013 at 10:13 PM, Ted Lemon > wrote: > >> [Bing] My previous argument above was assuming the use case > works, but someone might don’t prefer to use it. Then it is not our > goal to judge the case good or not. >> But if it doesn’t work at all, then I agree with you it should > not be listed, or make a clear statement the case is not applicable. > > Does IPv6 bonjour not work on a local wire without router > advertisements? > > > Yes, but it works with link-local addresses, so it doesn't need > DHCPv6 either. > > As Tore notes, per spec getting an IPv6 address via DHCPv6 is not > sufficient to talk to anyone at all, period. This is because there's > no way to guess the prefix size assigned to the link, And that is a problem. To solve it one may need the value of the prefix assigned on the link, > and so no way to create a routing table entry that allows you to send > packets. or may need the address of a default router containing the link-layer address, (to avoid needing NS/NA), and then get ICMP Redirect. > Stacks used to assume that everything is on link, but that > was reversed by RFC 4943. Informationally reversed, yes. Not all stacks assume everything is on link. Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Wed Dec 18 11:18:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E67F1AE17A for ; Wed, 18 Dec 2013 11:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.039 X-Spam-Level: X-Spam-Status: No, score=-115.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCxnvkvKfzZx for ; Wed, 18 Dec 2013 11:18:53 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC501AE171 for ; Wed, 18 Dec 2013 11:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4282; q=dns/txt; s=iport; t=1387394332; x=1388603932; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PiMhTAIGH4fc2x6xaiFi4VK/wB3Mj/QxcgD7Xb3UeUM=; b=VttWxekkWJKrYShbVQ+ivmORG0B31n9s0PtYFEKAqTybbJXIEfcR6Uls CGRMpX/A2f63u+nIMF2lOyGkBICvLTozd+k/0dgM6Yqc4bIVctAVjYTyF P4iyNhsJyWSCFs4oDSyV4wcPRsOcX/hlprKv2NgExhYYLgyG6FU6X9JBQ 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFALn0sVKtJXG//2dsb2JhbABTBoMKgQ24doEbFnSCJQEBAQMBdwIQAgEIRjIlAgQBDROHbgixfJhRF45PQweDI4ETBJAzgTGGMpIUgW2BPoIq X-IronPort-AV: E=Sophos;i="4.95,508,1384300800"; d="asc'?scan'208";a="292444573" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 18 Dec 2013 19:18:51 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBIJIp1e028778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 19:18:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 13:18:51 -0600 From: "Fred Baker (fred)" To: Owen DeLong , "Andrew Yourtchenko (ayourtch)" Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO/CX7Fr2YgpVF9kqVMzMOL0uhwg== Date: Wed, 18 Dec 2013 19:18:49 +0000 Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_2D7FAE82-985C-47E6-AFD2-30341801DDC7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 19:18:55 -0000 --Apple-Mail=_2D7FAE82-985C-47E6-AFD2-30341801DDC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> I don't think RAs are the single reason some people are resisting = deploying IPv6 at all. I think some people are resisting deploying IPv6 = because it needs to do one or both of two things for them - solve a = foreseeable problem that will effect them, or provide a tangible = benefit. If it won't do either of those things, then they don't = currently see any value from the effort involved. What are foreseeable = problems or tangible benefits is completely up to the perspective of the = decision maker. Eventually they'll see value in it, and deploy it. In = some cases, some people who could deploy IPv6 may never see any value in = deploying it, so they never will. >>=20 >> It's not binary. You can represent as a number both the amount of = pain that a given problem (or set of problems) causes, and the amount of = pain that the big change in the network like adding a new protocol = causes. >>=20 >> As soon as the first number is smaller than the second one, nothing = gets done. >>=20 >> Judging by the feedback I get from talking with people, even the = possibility of eventually eliminating RAs from their network might make = the second number smaller for a nontrivial amount folks, whose situation = dictates the DHCPv6. >=20 > I find this very hard to believe. RAs are virtually automatic and free = in 99% of cases. If you feel the need to tune them, then that's pretty = trivial if you know enough to tune them properly. Speaking as a pretty random individual. First, I don't think that the statement "they never will" holds. They = indeed never will while the equation remains the same - IPv6 costs them = something and doesn't give them a measurable ROI, or enough of one. The = premise of an adoption curve is that the equation indeed changes - the = cost of not deploying eventually exceeds the cost of deploying, and as a = result people deploy. The question here is not the current state, it's = the eventual state. The data tells me that the equation is slowly = changing. If we don't believe that, we're all wasting our time. As to the RA vs DHCP dispute, I think it's largely religious. If you = live in, or choose to live in, an RA/SLAAC world, and the information = elements in the RA meet your needs, by all means use it. If DHCP does = something an RA doesn't, and your network needs it, you're going to use = DHCP for at least that purpose. To the extent they are functionally = interchangeable - you can get an address from either, or advertise the = address of the DNS server, or etc - its the cook's choice.=20 The primary argument for the RA, from my perspective, is that it = identifies a preferred router on a LAN for a prefix that it is = advertising, and in the unusual case in which a large number of devices = simultaneously join a subnet (such as when the subnet is first turned up = or a network is renumbered), or if some other attribute needs to be = assigned to every device on a LAN in multicast fashion, it has improved = scaling characteristics. The primary argument for DHCP is control - you = can say what you mean to an individual system and have that not need to = be the same as you say to another, and if you have a requirement to know = for sure what system is using what address (for example for Source = Address Verification), you own the table. If it's your network, it will be about the policies your network = follows. There is no inherently "right" answer about policy, and as a = result there is no inherently "right" answer about the implementation of = policy. --Apple-Mail=_2D7FAE82-985C-47E6-AFD2-30341801DDC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSsfUYbjEdbHIsm0MRAicXAKC2nKwHWCEQq8Yi3+42fkJQ/PL53QCgv0XP fH4b6gM8r5mxC4GDkG7W1Jg= =SeT7 -----END PGP SIGNATURE----- --Apple-Mail=_2D7FAE82-985C-47E6-AFD2-30341801DDC7-- From brian.e.carpenter@gmail.com Wed Dec 18 11:33:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9AE1AE197 for ; Wed, 18 Dec 2013 11:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhH6w4xEuVHP for ; Wed, 18 Dec 2013 11:33:13 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 62E831AE146 for ; Wed, 18 Dec 2013 11:33:13 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id lf10so93536pab.28 for ; Wed, 18 Dec 2013 11:33:12 -0800 (PST) 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=A3zv+WdPbpxC6+EWRXI1xHYBaZV3ORm2ByjzbgsoK+c=; b=aPsvqwbntJB+zdbLmm46ESlkzKVs6bKunwm5eaICFiS1gRjqMTPdm3TfTfwu641L0I hOXf4pCJkQ/ChNRQEF9wzpGSlrSYe9HzWt4g3yuUPz6vvskR99ST6hEB5ry/TyYXom1s Z/ti4pH1kRylq5xPWxlDgj6wvJ4CVigqWxL9+3G+ED+gkFBtXrI6jyOxOI71lpMjZ61Y /o9zcP6DMVsJeG9RGMCQb8HhAbpSXR2/0X0fFlcUO2isaf99xkItae70bdINP/gBzyvx gTsrS/ZwKEfor+p2XfnLXE9u8NlosIC73zaEkAm8kRFHRAVambTGsoVij73hcE1Gj4QE ZMEA== X-Received: by 10.66.25.100 with SMTP id b4mr35635670pag.24.1387395192020; Wed, 18 Dec 2013 11:33:12 -0800 (PST) Received: from [192.168.178.20] (55.199.69.111.dynamic.snap.net.nz. [111.69.199.55]) by mx.google.com with ESMTPSA id oj6sm2423691pab.9.2013.12.18.11.33.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Dec 2013 11:33:11 -0800 (PST) Message-ID: <52B1F87B.4060600@gmail.com> Date: Thu, 19 Dec 2013 08:33:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Yourtchenko References: <20131127125213.17409.86382.idtracker@ietfa.amsl.com> <52AF9FAB.7060702@gmail.com> <52B090DC.7000304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-yourtchenko-ra-dhcpv6-comparison-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 19:33:15 -0000 On 19/12/2013 02:20, Andrew Yourtchenko wrote: > On Tue, 17 Dec 2013, Alexandru Petrescu wrote: > >> But in this email one seems to be suggesting a big recommendation DHCP >> vs RA, whereas something smaller and less contentious would be - among >> other things - a description of parameters configured by DHCP vs >> parameters configured by RA. > > I think that's how it started... (from my email attempting to specify > the properties of DHCP vs. RA in order to be able to easier choose DHCP > vs. RA). I suppose having an appendix with "what is configured today via > DHCP and what is configured via RA" is ok. IMHO it's a lot more than OK: it would be a highly useful objective reference. Brian From markzzzsmith@yahoo.com.au Wed Dec 18 12:46:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA6B1A1DFA for ; Wed, 18 Dec 2013 12:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLnwaZIcqNzR for ; Wed, 18 Dec 2013 12:46:43 -0800 (PST) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with SMTP id 1AA281AE0C8 for ; Wed, 18 Dec 2013 12:46:43 -0800 (PST) Received: from [98.139.214.32] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2013 20:46:41 -0000 Received: from [98.139.212.251] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2013 20:46:41 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 18 Dec 2013 20:46:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509333.63184.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 27843 invoked by uid 60001); 18 Dec 2013 20:46:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1387399601; bh=csufB8Ar51vrV98pJdIaDHG/O2DmWNgBoK1SvXFsYkA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=L9OfHqBZyXiiEVpLtB1vJBM78ckvUqidVUjkzuF1toD9Bjn8pj0if5Ei+C9VzSYLc2DTEcIrFaUn48ruJ+SkXTkguRj9g7GDDy/zeo3LTehvcI01bthjeqFuhck4ly4j12r4KVo/3AIVQJhZCPmp4pH4Qh3pNlORQT/ZS0X2VSo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rC1HqSRmhlbLXHgj2sT73aOxPsnFUx3yFMMkz4BEph7SL2jlGiSiYMO09ON7CBERiBLIRZFnZRE8AsxHgLwXd1St58OpTw3OZn3oiXnfAsl9XBb2UfOb7M5bDMJpQhtoTAMXvzM9HYTe++rFt8E2uIp4AonEVaz7tw9JgLi8Tvw=; X-YMail-OSG: 8OEHbIYVM1mO.qw.S6O.uqqZV_HSyZFUP_gYuszcJjAxu.o cvlLHTnfZrw8Qv2xt0PBTlMBY8ushghxC9l6Bxk5BoPNkXJ8SuYry38IzxyG UiUc2RgdQlACCTAt2xqI9KNzrWUjzYG2422VKtHfURXq61tBNDDLTa51EDms KR8x.6Sfc1kGQV0wVko8C_xrXYANgAByjQ5.88xi_cxmXsj71U1mEDEnuYUO TrZ7kVYwlpM_38m3VT1IqwlpCOQjVy43NuaptmzakZR6sMcPivrNxsZvsDgf SryxAkY6YYfcJsrmlqENmMXICDJ_1ogcyKURuIESOw4MQeSLhGMMExE_uBjH 5.bqarepz9YEhVsCQ4yTRyeqYc_L1EynpT_PZ0AH2TF_7k1ohL4r1nx_H9XW mZjrLNUPQBIQon1xkFF_89Ud_KbHm0eByYURhPtnI1H_iLSl2EnB1Gk1gQW5 1MUc.LaJ8YZZ1UNzFXV82UESRdRY9AshdtCOQWcFnY.EUWJstjVMX_2m73V1 UC2I5XugjplOkP8NFEppbCBFtVcEfDl_LCDivIkBC8jitfVbfLoPhcB4zC9j 6BTkecOGoZPs0 Received: from [150.101.221.237] by web161906.mail.bf1.yahoo.com via HTTP; Wed, 18 Dec 2013 12:46:41 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.Cj4gVG86IE93ZW4gRGVMb25nIDxvd2VuQGRlbG9uZy5jb20.OyBBbmRyZXcgWW91cnRjaGVua28gKGF5b3VydGNoKSA8YXlvdXJ0Y2hAY2lzY28uY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBUaHVyc2RheSwgMTkgRGVjZW1iZXIgMjAxMyA2OjE4IEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.170.612 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> Message-ID: <1387399601.27221.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Wed, 18 Dec 2013 12:46:41 -0800 (PST) From: Mark ZZZ Smith To: "Fred Baker \(fred\)" , Owen DeLong , "Andrew Yourtchenko \(ayourtch\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 20:46:45 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Fred Baker (fred) =0A> To: Owen DeLong ; Andrew Yourtchenko (ayour= tch) =0A> Cc: "v6ops@ietf.org WG" =0A> = Sent: Thursday, 19 December 2013 6:18 AM=0A> Subject: Re: [v6ops] New Versi= on Notification=09for=09draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)= =0A> =0A>>>> I don't think RAs are the single reason some people are =0A> = resisting deploying IPv6 at all. I think some people are resisting deployin= g =0A> IPv6 because it needs to do one or both of two things for them - sol= ve a =0A> foreseeable problem that will effect them, or provide a tangible = benefit. If it =0A> won't do either of those things, then they don't curren= tly see any value =0A> from the effort involved. What are foreseeable probl= ems or tangible benefits is =0A> completely up to the perspective of the de= cision maker. Eventually they'll =0A> see value in it, and deploy it. In so= me cases, some people who could deploy IPv6 =0A> may never see any value in= deploying it, so they never will.=0A>>> =0A>>> It's not binary. You can r= epresent as a number both the amount of =0A> pain that a given problem (or = set of problems) causes, and the amount of pain =0A> that the big change in= the network like adding a new protocol causes.=0A>>> =0A>>> As soon as th= e first number is smaller than the second one, nothing =0A> gets done.=0A>>= > =0A>>> Judging by the feedback I get from talking with people, even the = =0A> possibility of eventually eliminating RAs from their network might mak= e the =0A> second number smaller for a nontrivial amount folks, whose situa= tion dictates =0A> the DHCPv6.=0A>> =0A>> I find this very hard to believe= . RAs are virtually automatic and free in =0A> 99% of cases. If you feel th= e need to tune them, then that's pretty trivial =0A> if you know enough to = tune them properly.=0A> =0A> Speaking as a pretty random individual.=0A> = =0A> First, I don't think that the statement "they never will" holds. =0A> = They indeed never will while the equation remains the same - IPv6 costs the= m =0A> something and doesn't give them a measurable ROI, or enough of one. = The =0A> premise of an adoption curve is that the equation indeed changes -= the cost of =0A> not deploying eventually exceeds the cost of deploying, a= nd as a result people =0A> deploy. The question here is not the current sta= te, it's the eventual state. =0A> The data tells me that the equation is sl= owly changing. If we don't believe =0A> that, we're all wasting our time.= =0A> =0A> As to the RA vs DHCP dispute, I think it's largely religious. If = you live =0A> in, or choose to live in, an RA/SLAAC world, and the informat= ion elements in the =0A> RA meet your needs, by all means use it. If DHCP d= oes something an RA =0A> doesn't, and your network needs it, you're going t= o use DHCP for at =0A> least that purpose. To the extent they are functiona= lly interchangeable=A0 - you =0A> can get an address from either, or advert= ise the address of the DNS server, or =0A> etc -=A0 its the cook's choice. = =0A> =0A> The primary argument for the RA, from my perspective, is that it = identifies a =0A> preferred router on a LAN for a prefix that it is adverti= sing, and in the =0A> unusual case in which a large number of devices simul= taneously join a subnet =0A> (such as when the subnet is first turned up or= a network is renumbered), or if =0A> some other attribute needs to be assi= gned to every device on a LAN in multicast =0A> fashion, it has improved sc= aling characteristics. The primary argument for DHCP =0A> is control - you = can say what you mean to an individual system and have that not =0A> need t= o be the same as you say to another, and if you have a requirement to know = =0A> for sure what system is using what address (for example for Source Add= ress =0A> Verification), you own the table.=0A> =0A> If it's your network, = it will be about the policies your network follows. =0A> There is no inhere= ntly "right" answer about policy, and as a result =0A> there is no inherent= ly "right" answer about the implementation of =0A> policy.=0A=0AI'd suggest= the above statement is really "If it's your network and hosts, it will be = about the policies your network and hosts follows." I'm sure hosts were imp= lied, however this issue very much depends on host implementations and host= feature deployment, so I think it is worth specifically calling the hosts = out. =A0=0A=0AThe trouble is that the rapid rise of the BYOD/"cloud computi= ng"/smartphone/tablet model means that hosts and their IPv6 stack implement= ation capabilities are rapidly becoming less controlled and less able to be= dictated by the people operating the network, in networks where this level= of control is currently even =A0possible. I think we're seeing the split b= etween who operates the hosts and who operates the network significantly an= d rapidly widen.=0A=0ASo the network operator might want to only use DHCPv6= for everything, but if they need to facilitate connectivity for even just = one host that comes along that doesn't support DHCPv6 for everything, they'= ll need to continue to provide and support RAs too. I think that means RAs = will need to exist for at least 5 or perhaps 10 years for those networks wh= ere "DHCPv6 for everything" is the goal.=0A=0ARegards,=0AMark.=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A> ___________________________________________= ____=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mai= lman/listinfo/v6ops=0A> From nick@inex.ie Wed Dec 18 14:56:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446671AD8D5 for ; Wed, 18 Dec 2013 14:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk45vCwz2O-M for ; Wed, 18 Dec 2013 14:56:51 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9761ACCE5 for ; Wed, 18 Dec 2013 14:56:50 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBIMuex6086792 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Dec 2013 22:56:41 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52B22828.6080700@inex.ie> Date: Wed, 18 Dec 2013 22:56:40 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 22:56:53 -0000 On 18/12/2013 19:18, Fred Baker (fred) wrote: > As to the RA vs DHCP dispute, I think it's largely religious. If you > live in, or choose to live in, an RA/SLAAC world, and the information > elements in the RA meet your needs, by all means use it. If DHCP does > something an RA doesn't, and your network needs it, you're going to use > DHCP for at least that purpose. To the extent they are functionally > interchangeable - you can get an address from either, or advertise the > address of the DNS server, or etc - its the cook's choice. Fred, The single protocol barrier which stops me in theory from being able to completely remove RAs from my networks is dhcpv6 default gateway option. I understand that there are several other things that RA also handles, but defgw is sine qua non. I can live with /64 + 1500mtu everywhere, but it's not possible to have a functional auto-configured network without a default gateway option. Several IDs have been put forward to remedy this, but they were shot down not on any real technical basis but because of opinion. I understand that some people feel that there should be no gateway option in DHCPv6, and I respect that. But conversely, I would ask them to respect my opinion that on my networks, RAs add nothing except complication. I do not want SLAAC anywhere, and if I had a way of turning RAs off, I would do so tomorrow morning. But because of the sustained objections of a small number of people, I do not have this option. I dearly want to run a simpler network because simplicity is a sound engineering design goal. It's incredibly frustrating to have to run an entire extra protocol on my networks in order to provide a single auto-configuration option which could just as easily be supplied by dhcp. How can we fix this? Nick From tore@fud.no Wed Dec 18 15:10:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E361ACCE0 for ; Wed, 18 Dec 2013 15:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kQ3uosLxYkK for ; Wed, 18 Dec 2013 15:10:54 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 456BA1A1F48 for ; Wed, 18 Dec 2013 15:10:54 -0800 (PST) Received: from [2a02:fe0:c410:1d30:b6b6:76ff:fe17:2e83] (port=48186 helo=sloth.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VtQGQ-0003wA-6s; Thu, 19 Dec 2013 00:10:50 +0100 Message-ID: <52B22B79.3080605@fud.no> Date: Thu, 19 Dec 2013 00:10:49 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nick Hilliard , "Fred Baker (fred)" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> In-Reply-To: <52B22828.6080700@inex.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 23:10:56 -0000 * Nick Hilliard > The single protocol barrier which stops me in theory from being able > to completely remove RAs from my networks is dhcpv6 default gateway > option. > > I understand that there are several other things that RA also > handles, but defgw is sine qua non. I can live with /64 + 1500mtu > everywhere, but it's not possible to have a functional > auto-configured network without a default gateway option. Hi Nick, If you want (on-link) /64 routes to be signaled by DHCPv6 you need another (currently nonexistent, ttbomk) option for that as well. IA_NA leases are single address and do not imply any on-link prefixes. See RFC 5942 section 5. Tore From fred@cisco.com Wed Dec 18 15:38:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4391AD8F6 for ; Wed, 18 Dec 2013 15:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.039 X-Spam-Level: X-Spam-Status: No, score=-110.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kErsh7o6qUDA for ; Wed, 18 Dec 2013 15:38:12 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id BC5CC1AD8F2 for ; Wed, 18 Dec 2013 15:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1387409891; x=1388619491; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ns2PrsaL+N2bJ2qGPP6m6tqhnXyVWOcP+CdkivYWInQ=; b=BO75KHbOj/QZyuhwPXVwr15+eFlxz8Wn9/wnQceEVt+kpBZWoFTfjTjC hleCukBxWVZqPlIYrSY3QnyLnlpMUkOLoTWEbYel6l9h6uIX0is63ciPc UGQ9xhQkIa/My8nty+oIueCQeIdnFrH8Ietb6xZM8CV4ySCsHVi+slqDR Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAFUxslKtJXHA/2dsb2JhbABZgwqBDbkhgR0WdIIlAQEBAwF3AgULAgEIRjIlAgQOBQ6HbgiyBphOF48SB4MjgRMBA5AzgTGGMpIUgW2BPoIq X-IronPort-AV: E=Sophos;i="4.95,510,1384300800"; d="asc'?scan'208";a="7751228" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-3.cisco.com with ESMTP; 18 Dec 2013 23:38:11 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBINcBMK015487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 23:38:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 17:38:10 -0600 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO/Eo1+lITgLbqBUOmwKsgySw/+Q== Date: Wed, 18 Dec 2013 23:38:10 +0000 Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B22B79.3080605@fud.no> In-Reply-To: <52B22B79.3080605@fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_AA247ABE-8DC2-41DB-ACD9-DEB4A048F7BB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 23:38:17 -0000 --Apple-Mail=_AA247ABE-8DC2-41DB-ACD9-DEB4A048F7BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 18, 2013, at 3:10 PM, Tore Anderson wrote: > If you want (on-link) /64 routes to be signaled by DHCPv6 you need > another (currently nonexistent, ttbomk) option for that as well. Does that translate to "what is my prefix length" or some variation on = that theme? --Apple-Mail=_AA247ABE-8DC2-41DB-ACD9-DEB4A048F7BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSsjHibjEdbHIsm0MRAoLjAKC1C0cNP0ZMyEqhnO5TTmwrqqM2kACfT60e ThK3w0kTrx54sZigMN149lE= =V1Rp -----END PGP SIGNATURE----- --Apple-Mail=_AA247ABE-8DC2-41DB-ACD9-DEB4A048F7BB-- From tore@fud.no Wed Dec 18 15:47:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1B61ABBB1 for ; Wed, 18 Dec 2013 15:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTS2qp1HS1At for ; Wed, 18 Dec 2013 15:47:43 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 4664B1AC3DD for ; Wed, 18 Dec 2013 15:47:38 -0800 (PST) Received: from [2a02:fe0:c410:1d30:b6b6:76ff:fe17:2e83] (port=48414 helo=sloth.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VtQq0-0004gs-BW; Thu, 19 Dec 2013 00:47:36 +0100 Message-ID: <52B23417.7080907@fud.no> Date: Thu, 19 Dec 2013 00:47:35 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B22B79.3080605@fud.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 23:47:47 -0000 * Fred Baker (fred) > On Dec 18, 2013, at 3:10 PM, Tore Anderson > wrote: > >> If you want (on-link) /64 routes to be signaled by DHCPv6 you need >> another (currently nonexistent, ttbomk) option for that as well. > > Does that translate to "what is my prefix length" or some variation on that theme? Yes. The only way to signal an on-link prefix to hosts is the Prefix Information Option in RA (with L=1), as far as I know. So if Nick wants "/64 everywhere", DHCPv6 isn't sufficient, even if it did include the default gateway option he wanted. Tore From fred@cisco.com Wed Dec 18 16:28:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5611ACCD8 for ; Wed, 18 Dec 2013 16:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.039 X-Spam-Level: X-Spam-Status: No, score=-110.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q01p1Gwzd-tM for ; Wed, 18 Dec 2013 16:28:51 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id E8BC21AC4AB for ; Wed, 18 Dec 2013 16:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1387412929; x=1388622529; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xkpS7Y5K8YK3jtIzNj7mcEQp6fSOltM3QngVZk4erwQ=; b=auPdDPmkIy/W+ZhFDIQ1/swxBG855S+DD6yADqRXRXZvuHCF7JiUNJ03 Hy1DMLWizL2oYLbjs6FGDkVm2qcfyAxV9675CowNTGwlJEAq0V0TtjMKp DAoL7Bjct8LnSc00voK2k6i8MAqX6VpaSKGoVocfPW3ftsW2+TstP5zH5 U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAAo9slKtJXG//2dsb2JhbABZgwqBDbkhgRcWdIIlAQEBBHcCEAIBCBguMiUCBA4FDod2sWyYTBePEgeDI4ETAQOQM4ExhjKSFIFtgT6CKg X-IronPort-AV: E=Sophos;i="4.95,510,1384300800"; d="asc'?scan'208";a="7757850" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 19 Dec 2013 00:28:49 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBJ0SnYn027125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 00:28:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 18:28:49 -0600 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO/FFIk0gJUsRiT0uKFZtSuRKv3w== Date: Thu, 19 Dec 2013 00:28:48 +0000 Message-ID: <41DEF007-F7FE-49E1-9867-4EF386E89C19@cisco.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B22B79.3080605@fud.no> <52B23417.7080907@fud.no> In-Reply-To: <52B23417.7080907@fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_2046F77E-119F-467B-BE15-B8010C10545E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 00:28:52 -0000 --Apple-Mail=_2046F77E-119F-467B-BE15-B8010C10545E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 18, 2013, at 3:47 PM, Tore Anderson wrote: > * Fred Baker (fred) >=20 >> On Dec 18, 2013, at 3:10 PM, Tore Anderson >> wrote: >>=20 >>> If you want (on-link) /64 routes to be signaled by DHCPv6 you need >>> another (currently nonexistent, ttbomk) option for that as well. >>=20 >> Does that translate to "what is my prefix length" or some variation = on that theme? >=20 > Yes. The only way to signal an on-link prefix to hosts is the Prefix > Information Option in RA (with L=3D1), as far as I know. So if Nick = wants > "/64 everywhere", DHCPv6 isn't sufficient, even if it did include the > default gateway option he wanted. and perhaps more to the point, if he wants "/65 in domain X and /63 in = domain Z"... So your argument would be that he needs both a default gateway and a = prefix length. Is there anything else he needs? --Apple-Mail=_2046F77E-119F-467B-BE15-B8010C10545E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSsj2+bjEdbHIsm0MRAgQ1AKDw8ZyHwK95YotQzf9Pc7Q8AMiiuQCg+L5w 7vJ/q/PupTxkB91vbT7Ui9M= =svaM -----END PGP SIGNATURE----- --Apple-Mail=_2046F77E-119F-467B-BE15-B8010C10545E-- From fred@cisco.com Wed Dec 18 16:30:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F031A8034 for ; Wed, 18 Dec 2013 16:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.439 X-Spam-Level: X-Spam-Status: No, score=-114.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFNxl27vK7AI for ; Wed, 18 Dec 2013 16:30:56 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AF18E1ABBB1 for ; Wed, 18 Dec 2013 16:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3791; q=dns/txt; s=iport; t=1387413055; x=1388622655; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oxPyXfa0vUcTylyHkfMhk+jKt0J5h3LZFKnyIkcKsMk=; b=Pzeov12xGAVBnYF3+sfSytecoZiIiUH0j8zfEeAXxEVhTmtMCEDQBeAv rjs0zTwoVQsuqRlwqmU2fYAIeae+poxeUKPYMNxoWTdo9bJy8Cg1Ueb69 PrkUICLlsMya6hWpXJTxvS7omUxkkLtQpENQ9OOqb18CpCOBL8yNo6srf o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAIs9slKtJXHB/2dsb2JhbABZgwqBDbkhgRcWdIIlAQEBAwF3AgULAgEIGC4yJQIEDgUOh24IsWyYTBeOPlQHgyOBEwEDkDOBMYJPg2OSFIFtgT6CKg X-IronPort-AV: E=Sophos;i="4.95,510,1384300800"; d="asc'?scan'208";a="292502070" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 19 Dec 2013 00:30:55 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBJ0UsXu022652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 00:30:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 18:30:54 -0600 From: "Fred Baker (fred)" To: Nick Hilliard Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO/FGT9ATuW2rEhEOSVdCSR2Ta1g== Date: Thu, 19 Dec 2013 00:30:54 +0000 Message-ID: References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> In-Reply-To: <52B22828.6080700@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.114] Content-Type: multipart/signed; boundary="Apple-Mail=_A109D49B-8DB0-41E5-9D66-0E38C0C6E6A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 00:30:58 -0000 --Apple-Mail=_A109D49B-8DB0-41E5-9D66-0E38C0C6E6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 18, 2013, at 2:56 PM, Nick Hilliard wrote: > On 18/12/2013 19:18, Fred Baker (fred) wrote: >> As to the RA vs DHCP dispute, I think it's largely religious. If you >> live in, or choose to live in, an RA/SLAAC world, and the information >> elements in the RA meet your needs, by all means use it. If DHCP does >> something an RA doesn't, and your network needs it, you're going to = use >> DHCP for at least that purpose. To the extent they are functionally >> interchangeable - you can get an address from either, or advertise = the >> address of the DNS server, or etc - its the cook's choice. >=20 > Fred, >=20 > The single protocol barrier which stops me in theory from being able = to > completely remove RAs from my networks is dhcpv6 default gateway = option. >=20 > I understand that there are several other things that RA also handles, = but > defgw is sine qua non. I can live with /64 + 1500mtu everywhere, but = it's > not possible to have a functional auto-configured network without a = default > gateway option. >=20 > Several IDs have been put forward to remedy this, but they were shot = down > not on any real technical basis but because of opinion. >=20 > I understand that some people feel that there should be no gateway = option > in DHCPv6, and I respect that. But conversely, I would ask them to = respect > my opinion that on my networks, RAs add nothing except complication. = I do > not want SLAAC anywhere, and if I had a way of turning RAs off, I = would do > so tomorrow morning. >=20 > But because of the sustained objections of a small number of people, I = do > not have this option. >=20 > I dearly want to run a simpler network because simplicity is a sound > engineering design goal. It's incredibly frustrating to have to run = an > entire extra protocol on my networks in order to provide a single > auto-configuration option which could just as easily be supplied by = dhcp. >=20 > How can we fix this? This time wearing the hat that looks like a chair... Per charter, we're allowed to file internet drafts and send them (in = what any other SDO would call a "liaison") to working groups like 6man = or whatever, tell them their stuff is busted, and ask them to fix it. = Imagine just for fun we had a draft that said, in essence, "aw cm'on = guys, fix this", gave requirements ("we want to operate without the = periodic RA and to do that need ..."), listed the drafts that had = proposed a fix, and asked the relevant working group to spruce one of = them up to spec and adopt it? Imagine, God help us, that it even had = implementation experience behind it - "we prototyped the bits and pieces = we needed and found that we could in fact live without the RA". We'd have to have consensus behind the draft, of course. That implies a = discussion, potentially in London. Is that anywhere near Ireland? Do you know anyone that might be willing to write that draft - and then = contribute to the work in whatever-working-group that would actually = address this? --Apple-Mail=_A109D49B-8DB0-41E5-9D66-0E38C0C6E6A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSsj48bjEdbHIsm0MRAvtRAJ4qPKufCKJ3lyRkRiSPBim0iws2lQCg+q7Z w/+sg2a0m/2x3G1LcAg5ORo= =TJdC -----END PGP SIGNATURE----- --Apple-Mail=_A109D49B-8DB0-41E5-9D66-0E38C0C6E6A7-- From lorenzo@google.com Wed Dec 18 17:34:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5881AD8F5 for ; Wed, 18 Dec 2013 17:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEXCtM07Nk5D for ; Wed, 18 Dec 2013 17:34:38 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id C3EB51AD9AB for ; Wed, 18 Dec 2013 17:34:38 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id hk11so2693480igb.0 for ; Wed, 18 Dec 2013 17:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qopOJ2SiCGiRPJNezL2eqDrtI2qKeh7VZ/7bhWJLcC8=; b=VUpI9zSbJBfap198ACAw5h8x+wS0rB4mz69JhjVE+a3/5aiHV+96PpQhfLTuWpnnj0 DoOEXtSVwz8TXHbsWlFvM6epYkxsZqAqN9do3dImkWZ0r3ukX0hO4c900dlEzQxkARTw rF+OnLHgS1XS5ubdstb61EalnKDVsUDNqBqSfCD+SH20HAGKRdakXrAu8Hf9zL4h9HQH daUeTU90xSbQkfvrWIklT9iQRCcxGo59eZxIKLon6cHGZVhy5LX/lPcWF+3jovm28VBJ jXKuGyaRscSE+jFikLdb2INePoa+uAv9X1qilbbmlbfM8WKT09LNkMjuF6vcJNiZAgCc GbyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qopOJ2SiCGiRPJNezL2eqDrtI2qKeh7VZ/7bhWJLcC8=; b=SjMLEwPQVjFG4jcZcTmSdDas813rXwIUDV01O27/Q2MvKYAU3z62pnpwta66v1IGKv sFxLR0BlfipJsN/Y2G3pxMRspJPHNjG67exOS7vvU6SBSgJE9jaD4DJCYIucp0sSUCL6 LE65Z/12M2LJDqtGkSso8DJGSjlhBGcqhWZ3LTHT39XnHCy6N61DveA86DWMejc+AIuD m8plrUjDqNvR23iw49KssLqVTJlyFVi6Wwp+ZJnkAhLGApaAH6dlSi3RUXfXV1iVANMW StGrMHF1Y0oaLBthS8yQ1hyBF/u1dnrRTneFbpg9g0c3mHK4awnEaEqZbP4OQxjAX/ef pVQQ== X-Gm-Message-State: ALoCoQl2xTtiWz3oMop6ZZAj5+DRENUHg7Y/6t5CiEZ4lirIx14jN9VySMzFs4j/YLXEjtvQIeFnAmh+/jyyx4LqGR7Qloy8jBuE+SM2al19sRDW3Y8DNSqZNAvjPK/tUOEYsbURQ9am3Daykhb8wwosnaIYFLJXkeJAFps4KBy0TTPTSzBDyZdRmQf2WqmCW6Vy15ja5yrP X-Received: by 10.50.61.137 with SMTP id p9mr463771igr.45.1387416877051; Wed, 18 Dec 2013 17:34:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Wed, 18 Dec 2013 17:34:16 -0800 (PST) In-Reply-To: <52B22828.6080700@inex.ie> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> From: Lorenzo Colitti Date: Thu, 19 Dec 2013 10:34:16 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=047d7bdca5dc1ccf1f04edd92a5b Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 01:34:41 -0000 --047d7bdca5dc1ccf1f04edd92a5b Content-Type: text/plain; charset=UTF-8 On Thu, Dec 19, 2013 at 7:56 AM, Nick Hilliard wrote: > The single protocol barrier which stops me in theory from being able to > completely remove RAs from my networks is dhcpv6 default gateway option. > > I understand that there are several other things that RA also handles, but > defgw is sine qua non. I can live with /64 + 1500mtu everywhere, but it's > not possible to have a functional auto-configured network without a default > gateway option. > > Several IDs have been put forward to remedy this, but they were shot down > not on any real technical basis but because of opinion. > Can we stop flogging this dead horse please? This keeps getting proposed, every time in a different working group, and keeps failing to achieve consensus. It's a huge waste of time. I understand that you think that opinion is not a valid reason, but I would like to point out that yours is also an opinion. Yes, DHCPv6 allows you to configure more options than RAs, but it's also less flexible in some ways (e.g., doesn't support load-balancing over multiple routers, doesn't easily support deprecation, etc.). So I think it's clear that one is not necessarily better than the other. I understand the point of view "this is MY network, and in MY network, I want to use DHCPv6 ONLY", but remember that in many cases, the hosts that connect to your network are the same hosts that connect to other networks, and those host implementers probably also only want to reduce the number of scenarios they support. --047d7bdca5dc1ccf1f04edd92a5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Dec 19, 2013 at 7:56 AM, Nick Hilliard <nick@inex.ie> wro= te:
The single protocol barrier which = stops me in theory from being able to
completely remove RAs from my networks is dhcpv6 default gateway option.
I understand that there are several other things that RA also handles, but<= br> defgw is sine qua non. =C2=A0I can live with /64 + 1500mtu everywhere, but = it's
not possible to have a functional auto-configured network without a default=
gateway option.

Several IDs have been put forward to remedy this, but they were shot down not on any real technical basis but because of opinion.

Can we stop flogging this dead horse please? This keeps getting propo= sed, every time in a different working group, and keeps failing to achieve = consensus. It's a huge waste of time.

I understand that you think that opinion is not a valid= reason, but I would like to point out that yours is also an opinion. Yes, = DHCPv6 allows you to configure more options than RAs, but it's also les= s flexible in some ways (e.g., doesn't support load-balancing over mult= iple routers, doesn't easily support deprecation, etc.). So I think it&= #39;s clear that one is not necessarily better than the other.

I understand the point of view "this is MY network= , and in MY network, I want to use DHCPv6 ONLY", but remember that in = many cases, the hosts that connect to your network are the same hosts that = connect to other networks, and those host implementers probably also only w= ant to reduce the number of scenarios they support.
--047d7bdca5dc1ccf1f04edd92a5b-- From owen@delong.com Wed Dec 18 17:53:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D31ADBFF for ; Wed, 18 Dec 2013 17:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI83bApSkgAt for ; Wed, 18 Dec 2013 17:53:33 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 127131AD9AB for ; Wed, 18 Dec 2013 17:53:33 -0800 (PST) Received: from [172.16.142.113] ([156.39.96.253]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBJ1o891004388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Dec 2013 17:50:09 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBJ1o891004388 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1387417809; bh=ylOK9IihnDHwBNDm/Q1vbnzZY8g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=tHh8Qy6zJ6ChEtRFR8rG6QHSuS6qNW+H9ZGnAdIGkLo5SB9YoOexHn4vmxAkIiHVl fSYiIgeJ7oD0KvAXnLD0G0rRnwi0aLgap/M3PrvEHnF4oEzkIcZ0hkuLbfAB6xgSdA 7Sqc82CPF1v4rJfKveovmnD4Ijd9a79w4iNQbmnc= Content-Type: multipart/alternative; boundary="Apple-Mail=_CBB7A5DD-91D2-4776-A0AA-F371C3E2D7FA" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: Date: Wed, 18 Dec 2013 17:50:07 -0800 Message-Id: <64CDD9C6-B94E-43ED-B996-803B5DEDC551@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 18 Dec 2013 17:50:09 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 01:53:34 -0000 --Apple-Mail=_CBB7A5DD-91D2-4776-A0AA-F371C3E2D7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 18, 2013, at 11:18 AM, Fred Baker (fred) wrote: >>>> I don't think RAs are the single reason some people are resisting = deploying IPv6 at all. I think some people are resisting deploying IPv6 = because it needs to do one or both of two things for them - solve a = foreseeable problem that will effect them, or provide a tangible = benefit. If it won't do either of those things, then they don't = currently see any value from the effort involved. What are foreseeable = problems or tangible benefits is completely up to the perspective of the = decision maker. Eventually they'll see value in it, and deploy it. In = some cases, some people who could deploy IPv6 may never see any value in = deploying it, so they never will. >>>=20 >>> It's not binary. You can represent as a number both the amount of = pain that a given problem (or set of problems) causes, and the amount of = pain that the big change in the network like adding a new protocol = causes. >>>=20 >>> As soon as the first number is smaller than the second one, nothing = gets done. >>>=20 >>> Judging by the feedback I get from talking with people, even the = possibility of eventually eliminating RAs from their network might make = the second number smaller for a nontrivial amount folks, whose situation = dictates the DHCPv6. >>=20 >> I find this very hard to believe. RAs are virtually automatic and = free in 99% of cases. If you feel the need to tune them, then that's = pretty trivial if you know enough to tune them properly. >=20 > Speaking as a pretty random individual. >=20 > First, I don't think that the statement "they never will" holds. They = indeed never will while the equation remains the same - IPv6 costs them = something and doesn't give them a measurable ROI, or enough of one. The = premise of an adoption curve is that the equation indeed changes - the = cost of not deploying eventually exceeds the cost of deploying, and as a = result people deploy. The question here is not the current state, it's = the eventual state. The data tells me that the equation is slowly = changing. If we don't believe that, we're all wasting our time. Yep. > As to the RA vs DHCP dispute, I think it's largely religious. If you = live in, or choose to live in, an RA/SLAAC world, and the information = elements in the RA meet your needs, by all means use it. If DHCP does = something an RA doesn't, and your network needs it, you're going to use = DHCP for at least that purpose. To the extent they are functionally = interchangeable - you can get an address from either, or advertise the = address of the DNS server, or etc - its the cook's choice.=20 I think the idea of =93RA vs. DHCP=94 is absurd, at least without major = changes to the current protocol specifications. The current set of choices is {RA, RA+DHCP, Link-Local-Only, Static}. = As such, railing against RAs makes very little sense to me, but if there = is a legitimate argument for a use case where autoconf with DHCP and no = RAs, then I=92d like to know more about that use case so we might better = address it. So far, the =93we want to be able to eliminate RAs from our = network=94 camp hasn=92t yet responded with such details. Owen --Apple-Mail=_CBB7A5DD-91D2-4776-A0AA-F371C3E2D7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 18, 2013, at 11:18 AM, Fred = Baker (fred) <fred@cisco.com> = wrote:

I = don't think RAs are the single reason some people are resisting = deploying IPv6 at all. I think some people are resisting deploying IPv6 = because it needs to do one or both of two things for them - solve a = foreseeable problem that will effect them, or provide a tangible = benefit. If it won't do either of those things, then they don't = currently see any value from the effort involved. What are foreseeable = problems or tangible benefits is completely up to the perspective of the = decision maker. Eventually they'll see value in it, and deploy it. In = some cases, some people who could deploy IPv6 may never see any value in = deploying it, so they never will.

It's not binary. = You can represent as a number both the amount of pain that a given = problem (or set of problems) causes, and the amount of pain that the big = change in the network like adding a new protocol causes.

As soon = as the first number is smaller than the second one, nothing gets = done.

Judging by the feedback I get from talking with people, = even the possibility of eventually eliminating RAs from their network = might make the second number smaller for a nontrivial amount folks, = whose situation dictates the DHCPv6.

I find this = very hard to believe. RAs are virtually automatic and free in 99% of = cases. If you feel the need to tune them, then that's pretty trivial if = you know enough to tune them properly.

Speaking as a = pretty random individual.

First, I don't think that the statement = "they never will" holds. They indeed never will while the equation = remains the same - IPv6 costs them something and doesn't give them a = measurable ROI, or enough of one. The premise of an adoption curve is = that the equation indeed changes - the cost of not deploying eventually = exceeds the cost of deploying, and as a result people deploy. The = question here is not the current state, it's the eventual state. The = data tells me that the equation is slowly changing. If we don't believe = that, we're all wasting our = time.

Yep.

As to the RA vs DHCP dispute, I = think it's largely religious. If you live in, or choose to live in, an = RA/SLAAC world, and the information elements in the RA meet your needs, = by all means use it. If DHCP does something an RA doesn't, and your = network needs it, you're going to use DHCP for at least that purpose. To = the extent they are functionally interchangeable  - you can get an = address from either, or advertise the address of the DNS server, or etc = -  its the cook's = choice. 

I think the idea of = =93RA vs. DHCP=94 is absurd, at least without major changes to the = current protocol specifications.

The current = set of choices is {RA, RA+DHCP, Link-Local-Only, Static}.  As such, = railing against RAs makes very little sense to me, but if there is a = legitimate argument for a use case where autoconf with DHCP and no RAs, = then I=92d like to know more about that use case so we might better = address it. So far,  the =93we want to be able to eliminate RAs = from our network=94 camp hasn=92t yet responded with such = details.

Owen


=

= --Apple-Mail=_CBB7A5DD-91D2-4776-A0AA-F371C3E2D7FA-- From tore@fud.no Thu Dec 19 00:37:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9021AE215 for ; Thu, 19 Dec 2013 00:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFEZEGFuuo0s for ; Thu, 19 Dec 2013 00:37:47 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id A142A1AE0F2 for ; Thu, 19 Dec 2013 00:37:47 -0800 (PST) Received: from [2a02:fe0:c410:1d30:b6b6:76ff:fe17:2e83] (port=48921 helo=sloth.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VtZ71-0007Tg-PT; Thu, 19 Dec 2013 09:37:43 +0100 Message-ID: <52B2B056.1020802@fud.no> Date: Thu, 19 Dec 2013 09:37:42 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B22B79.3080605@fud.no> <52B23417.7080907@fud.no> <41DEF007-F7FE-49E1-9867-4EF386E89C19@cisco.com> In-Reply-To: <41DEF007-F7FE-49E1-9867-4EF386E89C19@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 08:37:49 -0000 * Fred Baker (fred) > and perhaps more to the point, if he wants "/65 in domain X and /63 in domain Z"... Indeed. Any onlink prefix, regardless of length, can only be signaled by RA/PIO today. > So your argument would be that he needs both a default gateway and a prefix length. Is there anything else he needs? While I can't speak for Nick, it would appear to me that with those two options available in DHCPv6, one would have the basic functionality needed to operate a network without RAs. So yes, I think so. If the host implementations support it, that is. Which might be a very big "if" indeed. Tore From alexandru.petrescu@gmail.com Thu Dec 19 02:09:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DF41AE219 for ; Thu, 19 Dec 2013 02:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE_DKvXQfR0w for ; Thu, 19 Dec 2013 02:09:51 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C11801AD79D for ; Thu, 19 Dec 2013 02:09:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBJA9iFv011097; Thu, 19 Dec 2013 11:09:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2D2472029EF; Thu, 19 Dec 2013 11:10:14 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1F9BC20284E; Thu, 19 Dec 2013 11:10:14 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rBJA9H3n002900; Thu, 19 Dec 2013 11:09:44 +0100 Message-ID: <52B2C5CD.4020206@gmail.com> Date: Thu, 19 Dec 2013 11:09:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tore Anderson , "Fred Baker (fred)" References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B22B79.3080605@fud.no> <52B23417.7080907@fud.no> <41DEF007-F7FE-49E1-9867-4EF386E89C19@cisco.com> <52B2B056.1020802@fud.no> In-Reply-To: <52B2B056.1020802@fud.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 10:09:53 -0000 Le 19/12/2013 09:37, Tore Anderson a écrit : > * Fred Baker (fred) > >> and perhaps more to the point, if he wants "/65 in domain X and /63 >> in domain Z"... > > Indeed. Any onlink prefix, regardless of length, can only be signaled > by RA/PIO today. I agree. It is not signalled by DHCP, nor by other ICMP messages. The prefix length is needed in many cases, such as onlink determination (to determine whether to send NS to a /128 multicast address prior to sending the packet, or otherwise send the packet to the default router), or for DAD which is optional in many cases. That does not mean one could not live without signalling the prefix length to the node. In a simple spartan step signalling the default route would be sufficient because that will prime over all other entries in the Default Router List and in the routing table because of its default prefix length 0 which is special. That default router would subsequently ICMP Redirect the Host which is itself a /128 entry in the routing table which would fit longest prefix match and all other failed. The subsequent NS/NA for that /128 address does not need any prefix length in its message fields. >> So your argument would be that he needs both a default gateway and >> a prefix length. Is there anything else he needs? > > While I can't speak for Nick, it would appear to me that with those > two options available in DHCPv6, one would have the basic > functionality needed to operate a network without RAs. So yes, I > think so. I would not oppose that combined need. Alex > > If the host implementations support it, that is. Which might be a > very big "if" indeed. > > Tore _______________________________________________ v6ops mailing > list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nick@inex.ie Thu Dec 19 04:57:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF991AC85E for ; Thu, 19 Dec 2013 04:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObdfYLvGw_-p for ; Thu, 19 Dec 2013 04:57:14 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7503F1A1F66 for ; Thu, 19 Dec 2013 04:57:13 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBJCv3bh092709 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 12:57:03 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52B2ED1E.1040108@inex.ie> Date: Thu, 19 Dec 2013 12:57:02 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 12:57:16 -0000 On 19/12/2013 01:34, Lorenzo Colitti wrote: > I understand that you think that opinion is not a valid reason, but I would > like to point out that yours is also an opinion. Yes, DHCPv6 allows you to > configure more options than RAs, but it's also less flexible in some ways > (e.g., doesn't support load-balancing over multiple routers, doesn't easily > support deprecation, etc.). So I think it's clear that one is not > necessarily better than the other. I'm not claiming that RAs are better than DHCPv6 or the other way around. If you want to run only SLAAC or benefit from any of the features of RAs+SLAAC, then that's great and I'm very happy for you. I'm just stating that for my deployment scenarios, I specifically do not want the extra stuff that RAs/SLAAC provide like load-balancing over multiple routers, deprecation of defgws, multiple networks/gateways per l2 domain and all that. On the other hand, I need to run DHCPv6 because RAs do not provide me with the technical knobs that I need. These include address assignment (rather than slaac), and other dhcp-only knobs. In this context, RAs serve only to provide defgw and (as Tore kindly reminded me) prefix assignment, and then hand everything off to DHCPv6. Leaving aside the operational issues associated with running separate configuration on separate systems for the same end goal of autoconfiguration, from a protocol simplicity point of view, this approach is not very sensible because, we have an entire protocol dedicated to handling something that with a modest amount of effort could probably be handled by dhcpv6. I'm sorry you feel this is a dead horse. My take is that if we're designing a protocol which has an expected lifetime of $manyyears, then protocol simplicity should be high on the list. Given the amount of recent noise on this list discussing the interaction between RA+DHCP, it's abundantly clear that simplicity has been lost in favour of confusion. Simplicity is a critically important design goal for anything related to engineering, and the old maxim is true: "everything should be kept as simple as possible, but no simpler". If possible, I'd really like if we could have a non-heated discussion about the technical pros and cons of whether standalone DHCPv6 is viable. I know that for my use cases, it would be a highly desirable endpoint, but I understand that other people have different deployment requirements. Nick From lorenzo@google.com Thu Dec 19 05:40:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7073C1AD986 for ; Thu, 19 Dec 2013 05:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhh0mOdeRpyH for ; Thu, 19 Dec 2013 05:40:51 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F02231A82E2 for ; Thu, 19 Dec 2013 05:40:50 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so1296518ief.20 for ; Thu, 19 Dec 2013 05:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=r20a734eYZYzTYuepu5TPuAs0hX1y6ztuhDS9roaIeg=; b=YM06fT+hJH4Oh6ZPu64FsSxSmewdb2wso05EE6GzG6hSCYLQHcxdFFN3QTnGPVKtmV uFajdUETwadEHVknelS4hW5EPgiTZxucx1k5AFcsS2qp8L7evh+YoK1WOlOvy9ZmVzu0 1sWxNFNsgAmfA4Srso7/Qk3wt0c9shbyt3o49VwKRc9B4Q1G14gPspraIN8odUOyrOs4 rY0qhrq5Egimx4eKMzDgucQr6aHkUn/lp0gRkDG86rfywX/j1qjggdlsS3jxf3mUtM4h PZTBYTCuG8rbcPC1i56pTRfEAeCi5PArJmKCqaTI0TEYGHbQUsqU53WHvXwW/qQlNUAR ZSJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=r20a734eYZYzTYuepu5TPuAs0hX1y6ztuhDS9roaIeg=; b=QMp1gtnpotUWbfn4HMjw74aOj/jo6vExZ//Sjq7zxOrdu65zDVwrxs8S6in62QoAdL pbT8W6zO78j6beppHcX72qvV8/kHnz+MQCQUm1/3dtEV10tMV9RYzF82Ql7naZYYMu3T iXoWjLHcQihrMW3NWIwXr35ZuvLnCw/WiUqcR7sgrVElj/tyi1XBiWUXh2RI5LXd++o6 LqOCntELnPPzd+V32UIlkeGbrGMCjnfRJuTxZWalDnTcpfJFgzEO9i9YgonFQ39Kh2kC yMUvWlIKQ/bD0FX5COb4feNS5o0LqkKyr6wTu+g/CmWMmQPQ3kY8YnIbzpXBYqeUjVqv m/xg== X-Gm-Message-State: ALoCoQlFVJIeyf7DzpdU6mnT9MS3FTGKXuzQcvTcgINRPy9vxinQnPkKonWOXanpHAVcORFbLMpFEghdtVm4EdHK3VU9Aa6oqUGDpdKXGglROoWtgnhLXOaZRNVcGB7Oa3Wb9c/4ezUxzEw76WMfGe8Y2SusWdcC9BQAYdKiDe29xW48SNzQsequcxio6+tZomN9mRJx/UXq X-Received: by 10.50.176.137 with SMTP id ci9mr2695308igc.31.1387460448903; Thu, 19 Dec 2013 05:40:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 19 Dec 2013 05:40:27 -0800 (PST) In-Reply-To: <52B2ED1E.1040108@inex.ie> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> From: Lorenzo Colitti Date: Thu, 19 Dec 2013 22:40:27 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=089e0111e0da3313c404ede34f13 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 13:40:52 -0000 --089e0111e0da3313c404ede34f13 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 19, 2013 at 9:57 PM, Nick Hilliard wrote: > Simplicity is a critically important design goal for anything related to > engineering, and the old maxim is true: "everything should be kept as > simple as possible, but no simpler". > But what you propose is not simple. In fact, far from it. What you propose requires a DHCPv6 server that's always up and perpetually maintains state, and it requires that you run VRRP between the routers because DHCPv6. If you were designing a system from the ground up I'd wager you'd never design it like that. So why do it like that, then? Because "we already run DHCPv6 for other reasons, so let's just use it"? Isn't that a bit of a sunk cost fallacy? If possible, I'd really like if we could have a non-heated discussion about > the technical pros and cons of whether standalone DHCPv6 is viable. > Oh, it is viable. We know it works - after all, we do it in IPv4. It works well, because in IPv4 we have VRRP, things don't change often, and we have NAT. But many people feel that this time around we can do better than that. --089e0111e0da3313c404ede34f13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 19, 2013 at 9:57 PM, Nick Hilliard <nick@inex.ie> wrote:<= br>
Simplicity is a criti= cally important design goal for anything related to
engineering, and the old maxim is true: "everything should be kept as<= br> simple as possible, but no simpler".

But what you propose is not simple. In fact, far from it. What you propo= se requires a DHCPv6 server that's always up and perpetually maintains = state, and it requires that you run VRRP between the routers because DHCPv6= . If you were designing a system from the ground up I'd wager you'd= never design it like that. So why do it like that, then? Because "we = already run DHCPv6 for other reasons, so let's just use it"? Isn&#= 39;t that a bit of a sunk cost fallacy?

If possible, I'd really l= ike if we could have a non-heated discussion about
the technical pros and cons of whether standalone DHCPv6 is viable.

Oh, it is viable. We know it works - after all= , we do it in IPv4. It works well, because in IPv4 we have VRRP, things don= 't change often, and we have NAT. But many people feel that this time a= round we can do better than that.
--089e0111e0da3313c404ede34f13-- From Ted.Lemon@nominum.com Thu Dec 19 05:44:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22B41ADBD7 for ; Thu, 19 Dec 2013 05:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 803ZAyhUusWy for ; Thu, 19 Dec 2013 05:44:07 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 802171ACCD9 for ; Thu, 19 Dec 2013 05:44:07 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUrL4JSwn1xWczRRtBshbGhYKybVex6Hi@postini.com; Thu, 19 Dec 2013 05:44:06 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B03771B82E5 for ; Thu, 19 Dec 2013 05:44:05 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 891A1190043; Thu, 19 Dec 2013 05:44:05 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Dec 2013 05:44:00 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Thu, 19 Dec 2013 08:43:58 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 13:44:08 -0000 On Dec 19, 2013, at 8:40 AM, Lorenzo Colitti wrote: > What you propose requires a DHCPv6 server that's always up and = perpetually maintains state, and it requires that you run VRRP between = the routers because DHCPv6. Hm, would VRRP help us with the homenet problem? ;) From lorenzo@google.com Thu Dec 19 05:47:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DA61AD948 for ; Thu, 19 Dec 2013 05:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxBx7JBzFx07 for ; Thu, 19 Dec 2013 05:47:37 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6A71A1F62 for ; Thu, 19 Dec 2013 05:47:36 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so11944046igb.0 for ; Thu, 19 Dec 2013 05:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=00ZIidV+9kVtwXF87poSS/dYRZaOuMDw7emSkAetyR4=; b=msZbE/A8RU3dwBeQlZRPgYCJhk8+jKRh//fGDO9fsdIOmRRAlCr9YQa/f4GIX1ewOi FgR/KRpPqY9PgUIap4QBiFKCKJe1sFhbs0zcP74t+PHFJUr2lPO4iNt4+NyaPdNxMb/r 23v+0rIg0IdccZmQm5bfdjkyzun1ERO6NHzSepMr9d5H78QYNyxVvK2oXtlR151q6jVs ZdW9NrNqfIquUQeglBsOThVZNMeh2EIKc+rgD+4LC5IPld+8Bpt6KITjMoANcbl0TCb2 aNAtPEvUQcKAwv8bs58cAWkGcNLyvc4RZjDzPjHkN+vCz1wuKbiHOGvwQ3ZStW3zft3a tzJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=00ZIidV+9kVtwXF87poSS/dYRZaOuMDw7emSkAetyR4=; b=S/KH1oKciGHR8LHh7M1jHb5jtI97RnxzHz0FgI1kEN9TrLWMLOwZ31Zcss6eMs9+eP 6zrjBncHwiWu+58KK8q+yuHELP+aDycb9kyjeMHimWTYauhMHeHGsAOTlH3QHWERiu4U D++rUWlUWANAvHDDBRc1PGA6f48BNYCc7qR4raZKht+b7jjYAmYv5q0q+xEdY2H15iBT 7bNDVVPIM92hYqhGwJapnz1frUoB5ZI6wzOOg6UuduSO5MrRRvcXZGBuOPqkapg/uaTI njCGXq+oHLot/S/0b3KPz36jIkJm2RIxCU0FnmfXQuG5DiPx1oGRO7fB5KnXPhgHWiF9 2mtA== X-Gm-Message-State: ALoCoQlRnibLMmljqjbUBw0b0joDCrd4AYTaLDtJOzAs9Bk0XcsmI5sWSZpiSxhidebFYlY/r1Z8alUdrsYiiXQjxNRZ3DesCElGNcBwP8KkRckjvjCg+0rpncGiPi6U163qgux8m0MSARKuzXWbMWF77duja7ehIrEArgreqiuYJp8gUbVBXbtRTZyhaQfla/MewRVBeCC0 X-Received: by 10.50.176.137 with SMTP id ci9mr2725751igc.31.1387460855192; Thu, 19 Dec 2013 05:47:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 19 Dec 2013 05:47:15 -0800 (PST) In-Reply-To: <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> From: Lorenzo Colitti Date: Thu, 19 Dec 2013 22:47:15 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0111e0da69f20804ede3673d Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 13:47:38 -0000 --089e0111e0da69f20804ede3673d Content-Type: text/plain; charset=UTF-8 On Thu, Dec 19, 2013 at 10:43 PM, Ted Lemon wrote: > > What you propose requires a DHCPv6 server that's always up and > perpetually maintains state, and it requires that you run VRRP between the > routers because DHCPv6. > > Hm, would VRRP help us with the homenet problem? > > ;) > Sure! That's the DHCP way. Make the configuration procotol completely static, then realize that failures cause outages, and then be build redundancy into your services because you've chosen a client communication protocol that doesn't allow updates. Awesome :-) I always think that the biggest lie in DHCP is that D at the beginning. It's not dynamic. It should have been called SHCP. :-) --089e0111e0da69f20804ede3673d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 19, 2013 at 10:43 PM, Ted Lemon <ted.lemon@nominum.com>= wrote:
> What you propose requires a DHCPv6 = server that's always up and perpetually maintains state, and it require= s that you run VRRP between the routers because DHCPv6.

Hm, would VRRP help us with the homenet problem?

;)

Sure! That's the DHCP way. Make = the configuration procotol completely static, then realize that failures ca= use outages, and then be build redundancy into your services because you= 9;ve chosen a client communication protocol that doesn't allow updates.= Awesome :-)

I always think that the biggest lie in DHCP is that D a= t the beginning. It's not dynamic. It should have been called SHCP. :-)=
--089e0111e0da69f20804ede3673d-- From Ted.Lemon@nominum.com Thu Dec 19 06:05:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4B51ADF26 for ; Thu, 19 Dec 2013 06:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLnxI2rTcMnP for ; Thu, 19 Dec 2013 06:05:05 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5751ADBCE for ; Thu, 19 Dec 2013 06:05:05 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUrL9D2u5IrhYYWJ+KQzvWbPPuthSdUWv@postini.com; Thu, 19 Dec 2013 06:05:03 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 84E811B82E9 for ; Thu, 19 Dec 2013 06:05:03 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 77D58190043; Thu, 19 Dec 2013 06:05:03 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Dec 2013 06:05:03 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Thu, 19 Dec 2013 09:05:01 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 14:05:07 -0000 On Dec 19, 2013, at 8:47 AM, Lorenzo Colitti wrote: > Sure! That's the DHCP way. Make the configuration procotol completely = static, then realize that failures cause outages, and then be build = redundancy into your services because you've chosen a client = communication protocol that doesn't allow updates. Awesome :-) I was being slightly ironic, but also sort of serious, in the sense that = the thing you are saying DHCP fails at, that requires additional = complexity, is essentially the same problem as needs to be addressed for = homenets: how to do routing when there's more than one default router. = Although in a _very limited_ sense this is solved in the single-homed = dual-router RA case, the problem as a whole is unsolved. If it were = solved, we would not need VRRP in the dual-router single-home = single-failure case. I'm not saying we should try to solve it here, merely pointing out that = the case you are making has wider implications, and that in fact even = with RA, your hosts will be happier if you are running VRRP during the = outage scenario you describe. From lorenzo@google.com Thu Dec 19 06:11:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B41AD9A9 for ; Thu, 19 Dec 2013 06:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swi2wOcuOiDK for ; Thu, 19 Dec 2013 06:11:10 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id B9B311A1F66 for ; Thu, 19 Dec 2013 06:11:10 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so12001871igb.0 for ; Thu, 19 Dec 2013 06:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vnhq1RYpoaqysmc1kO1kmsmQKhseK6ELEf1YUNK5QiQ=; b=Q8HvXADbtfqhchQbOVRX5HbcZYl3J+I4Qn6o1T813JPF+uptS6UbzpgsrwDo/+8iLg oGrCdZl5N9KhOUzuizV1xCs2UiEf1c/XJfMg3KLejpsKkwB7b9qs+J+lywKTNiy83Ml3 ixFuVMF78T2IDS22GVwwDIJDlvISqZg6E5F1H1cXuUtyxm6dyfAGe9AbBNDz9RZVMbvl sbPeDVdWAKFtPHVsF1kspqSrVYTua/5kSXjT9WYiYMOTatyLXKy/XvUivF0+53U5xFc8 aYLdG+ylY8zSoObs6+2++h6VUh1HdCEhmtKFaYRCOzZVF1sg0rOWtKDHnFdbVtfGkAzj wxqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vnhq1RYpoaqysmc1kO1kmsmQKhseK6ELEf1YUNK5QiQ=; b=IZxwiRC/rmTe5MBd5S3BSppTD4Rcq8cTCPegnXkhc9AFNuWdVsQCxT8vIjxURCcWOZ Am7I66Q+uRlzvXbj8zkIwOBJrt3XsJFrT87O8o3F5AzuNcp7uA+NfVNTTy1rmnS7R9Z1 HA2xOPVjXfclzMoqcYYTLxu+hv7wjd4pNzqnQAY8uZRZySz4OW8n2A5mfbdponEuJhKM Sn77jpfe55QcUT+gE4K9z0qnx/JQhrRLgFsWoWXT5+H+6yTZ/qlV4zNwgbwey4dCyxyA +zjQw/shhkEJaNxmCGhOVbHmLYCbvVnwMmtdY6rLTOYd9K1GZSbhFF3Uti0560laAbZS p2cA== X-Gm-Message-State: ALoCoQm8JRFl6ab/oHa6ypNhouTXwGh92nulvIjvkiGdPNgL3HVOZ1tMKPjokUeZJMFOn7VWQZZIdCKfekmT2YJSk40K7gRrCsNJWlC1jRnTvAZ+nVepWC03ucAGVQtKkDFwlbQNgYngQ4weB2iqyd9aOc4CAkMhI4P/c5FDqWnAp5gPl2zTCnLGGnyUhPEuFC0P9u2vaxNK X-Received: by 10.50.176.137 with SMTP id ci9mr2840871igc.31.1387462268801; Thu, 19 Dec 2013 06:11:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 19 Dec 2013 06:10:48 -0800 (PST) In-Reply-To: <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> From: Lorenzo Colitti Date: Thu, 19 Dec 2013 23:10:48 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0111e0daabf5f404ede3bb6a Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 14:11:12 -0000 --089e0111e0daabf5f404ede3bb6a Content-Type: text/plain; charset=UTF-8 On Thu, Dec 19, 2013 at 11:05 PM, Ted Lemon wrote: > I'm not saying we should try to solve it here, merely pointing out that > the case you are making has wider implications, and that in fact even with > RA, your hosts will be happier if you are running VRRP during the outage > scenario you describe. > In homenet, what needs to be solved that can't be solved with fast NUD timers and RAs from multiple routers. You don't need subsecond convergence in the home, right? --089e0111e0daabf5f404ede3bb6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 19, 2013 at 11:05 PM, Ted Lemon <ted.lemon@nominum.com>= wrote:
I'm not saying we should try to solve it here, merely pointin= g out that the case you are making has wider implications, and that in fact= even with RA, your hosts will be happier if you are running VRRP during th= e outage scenario you describe.

In homenet, what needs to be solved that c= an't be solved with fast NUD timers and RAs from multiple routers. You = don't need subsecond convergence in the home, right?
--089e0111e0daabf5f404ede3bb6a-- From Ted.Lemon@nominum.com Thu Dec 19 06:21:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0EF1ADBCE for ; Thu, 19 Dec 2013 06:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bsy4lMtypCMq for ; Thu, 19 Dec 2013 06:21:28 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 11EF91ACC8A for ; Thu, 19 Dec 2013 06:21:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUrMA5ipjF7oIGJUEWp8QdFKyqOuha9u0@postini.com; Thu, 19 Dec 2013 06:21:26 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4F0851B82EA for ; Thu, 19 Dec 2013 06:21:26 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2E8A8190043; Thu, 19 Dec 2013 06:21:26 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Dec 2013 06:21:26 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Thu, 19 Dec 2013 09:21:24 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <09D891E7-4305-4627-B52C-CD5D4522FD7E@nominum.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 14:21:29 -0000 On Dec 19, 2013, at 9:10 AM, Lorenzo Colitti wrote: > In homenet, what needs to be solved that can't be solved with fast NUD = timers and RAs from multiple routers. You don't need subsecond = convergence in the home, right? If a neighbor goes down, there's up to roughly a 30-second delay before = failing over to the other router. That's pretty slow=97not slow enough = to kill a TCP connection, but slow enough that I will already have = assumed my video stream has failed. Also, we aren't talking about "in the home" in Nick's case. From nick@inex.ie Thu Dec 19 06:34:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B311ADF78 for ; Thu, 19 Dec 2013 06:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1uPS682t1s3 for ; Thu, 19 Dec 2013 06:34:28 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 92E191ADF32 for ; Thu, 19 Dec 2013 06:34:27 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBJEYI1o093364 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 14:34:19 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52B303EA.80602@inex.ie> Date: Thu, 19 Dec 2013 14:34:18 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ted Lemon , Lorenzo Colitti References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> <09D891E7-4305-4627-B52C-CD5D4522FD7E@nominum.com> In-Reply-To: <09D891E7-4305-4627-B52C-CD5D4522FD7E@nominum.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 14:34:31 -0000 On 19/12/2013 14:21, Ted Lemon wrote: > Also, we aren't talking about "in the home" in Nick's case. no, I'm talking about datacentre deployments, although the principals are also applicable to corporate / campus / enterprise networks where many operators that I know would frankly prefer not to have client devices make up their own minds about how to handle the connectivity that's provided to them. Nick From nick@inex.ie Thu Dec 19 06:46:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A051ADF5D for ; Thu, 19 Dec 2013 06:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGrImrkMGMmz for ; Thu, 19 Dec 2013 06:46:56 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6521ADF5B for ; Thu, 19 Dec 2013 06:46:56 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBJEklvB093514 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 14:46:47 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52B306D7.3030604@inex.ie> Date: Thu, 19 Dec 2013 14:46:47 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 14:46:58 -0000 On 19/12/2013 13:40, Lorenzo Colitti wrote: > But what you propose is not simple. In fact, far from it. What you propose > requires a DHCPv6 server that's always up and perpetually maintains state, > and it requires that you run VRRP between the routers because DHCPv6. Probably I'm not alone in considering dhcp servers to be critical to a functional DHCP based network. But as I said, I need DHCPv6 anyway and things will break if it's not available. Re: FHRPs, they have very predictable and stable failover characteristics and in the many years that I've been using them, they've performed incredibly well. As I said, if you want to use gateway deprecation on your networks, I'm happy for you, but I don't want to use this feature because its technical characteristics are not as consistent as FHRPs, nor as fast for handling failover. > If you were designing a system from the ground up I'd wager you'd never > design it like that. So why do it like that, then? Can we stick to technical discussion? > Because "we already > run DHCPv6 for other reasons, so let's just use it"? Isn't that a bit of > a sunk cost fallacy? It's a sunk cost reason, not a sunk cost fallacy, and it's only one reason out of several I don't want RAs on my network. Please let's stick to technical discussion rather than advocacy. > Oh, it is viable. We know it works - after all, we do it in IPv4. It works > well, because in IPv4 we have VRRP, things don't change often, and we have > NAT. But many people feel that this time around we can do better than that. I have looked at RA/SLAAC and its technical characteristics do not suit my use cases. Can you accept this and that I actually understand the differences between SLAAC, stateful configuration via dhcp and what each brings to the table, and that I still do not want SLAAC anywhere because it doesn't work for me? I'm ok about the fact that it may work very nicely for you. Nick From lorenzo@google.com Thu Dec 19 08:26:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE7B1ACD00 for ; Thu, 19 Dec 2013 08:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxJrg8zBdlkL for ; Thu, 19 Dec 2013 08:26:04 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35F1ACCFA for ; Thu, 19 Dec 2013 08:26:04 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so12350984igb.0 for ; Thu, 19 Dec 2013 08:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xSCNB1L3qeHPLMIx1MQCKUg0Mk6siVKcUPfefKnomSM=; b=XqRgyGPwKl/IxDnGWbsF7utv4PwrTyUjhsVIlUjMTAvQcq+IdisKqB57LKZYTUYUgM ofBYdyTkxJmu+XwX0wetNGWpoYmFyaEVrTKlt2yYjBRHO6rrgq2BMwpYctEIuvFjYjHK GeboMuKwBuCj/tAybQuhEedB84X3xWSYQDo9AvwsDzuwUr/G6oV4RUeajznBKOl7yXqx eurdqQiLYHlvJ73tnqYjMIzSnQiIcY/OsLho6agHivU6F1QkpuyT+Urs4KClkrGUgCkH JCBq0x+AnL4q0hIJ1yVWvfINGxpzdfvC0dt2UK/TXlP7E1ezqTO+0fSlnYIDETmp3+qv jSgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xSCNB1L3qeHPLMIx1MQCKUg0Mk6siVKcUPfefKnomSM=; b=f7fwYjkk15YJV1Ar62oKFMxYvREGi3uGsvp+xRpr6jvuEy07Jwr9z4LTYC12cDcb5f TIsswjzU33+rWO7nr4RBrtLwx1T1FTMK62OoAmWtxl1MoPLomvw/3CvS+7tdLngOFleF gA2l5gIju3eqwlNuPeJa2DyZAXQZSUxwL7d0ykULYLMDIjx/sN5vBow/P6UGoQIzfpuo Gbwf1DSJNnxPe4bPceMYbYwnoc253kM8ulzDaXGpYc4JNVjTkc68e/iMkrHDjtUBhuQR CeJuTcudKm3mC0HHPgMxoHjWmAHFcsqMebIELFVyRZKszZklEN/DUg8H4HzUD8xBmoHz zTHQ== X-Gm-Message-State: ALoCoQmVPN9R0ynbDkstRdmWh1eBXJ70P6oR+q5UQdDnf8oAc6jQldP3PMO0jPX1NKoTrQurultj3WzaIenEcqDHgNZDhq3T7fSA9FLqgMUEfgQbgh6x0vuCiZo+IHRZM+2dabRM7PVYwrl6cHYhkTxGo8IiInCvoP83s9ARQRMn/WuAVbDlEDwu0NKXC30goJVSGJt9haFj X-Received: by 10.50.110.74 with SMTP id hy10mr3692943igb.0.1387470362508; Thu, 19 Dec 2013 08:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.7.36 with HTTP; Thu, 19 Dec 2013 08:25:41 -0800 (PST) In-Reply-To: <52B306D7.3030604@inex.ie> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <52B306D7.3030604@inex.ie> From: Lorenzo Colitti Date: Fri, 20 Dec 2013 01:25:41 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=047d7bf182d218333704ede59e36 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 16:26:06 -0000 --047d7bf182d218333704ede59e36 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 19, 2013 at 11:46 PM, Nick Hilliard wrote: > > But what you propose is not simple. In fact, far from it. What you > propose > > requires a DHCPv6 server that's always up and perpetually maintains > state, > > and it requires that you run VRRP between the routers because DHCPv6. > > Probably I'm not alone in considering dhcp servers to be critical to a > functional DHCP based network. But as I said, I need DHCPv6 anyway > and things will break if it's not available. > Fine, but please don't say it's simpler. It's not - it has way more moving parts. > > If you were designing a system from the ground up I'd wager you'd never > > design it like that. So why do it like that, then? > > Can we stick to technical discussion? > We can, but it won't get us anywhere. You've said that you want to run your network with DHCPv6 because RAs don't suit your requirements, and I'll say that I want to run my network with RAs because DHCPv6 doesn't suit my requirements. We will both have valid reasons, and probably we'll even concede that in each other's networks the other's solution might be better. But once we reach that point, we're still stuck. Because the only way forward from there is to conclude that we need to define two completely autonomous and competing systems to provision the same protocol on the same host implementations, and choose one or the other depending on the deployment scenario. This is a bad outcome, because hosts that want to work everywhere (and what host doesn't?) need to implement both protocols. The resulting complexity - which is more than 2x, because in addition to the two protocols you have to define and implement rules to deal with their interaction - pushes costs up for everyone, because everyone uses hosts, including me and you. That's why I say this is a dead horse - because there *is* no single technically correct answer. The community has been through this exercise many times. People who want to put routing in DHCP and people who don't have had arguments in several working groups, each time with no conclusion, resulting in a waste of everyone's time. Let's not repeat that, because it isn't really in anybody's interest. Instead, what we can do is document the semantic differences and properties of the two protocols. After that, what we might be able to do is get consensus on criteria for what should go into RA and into DHCPv6 in the future. I think those are much mpre useful goals to pursue. --047d7bf182d218333704ede59e36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 19, 2013 at 11:46 PM, Nick Hilliard <nick@inex.ie> wrot= e:
> But what you propose is not simple. In fact, far fro= m it. What you propose
> requires a DHCPv6 server that's always up and perpetually maintain= s state,
> and it requires that you run VRRP between the routers because DHCPv6.<= br>
Probably I'm not alone in considering dhcp servers to be critical= to a
functional DHCP based network. =C2=A0But as I said, I need DHCPv6 anyway an= d=C2=A0things will break if it's not available.
Fine, but please don't say it's simpler. It's not = - it has way more moving parts.
=C2=A0
> If you were design= ing a system from the ground up I'd wager you'd never
> design it like that. So why do it like that, then?

Can we stick to technical discussion?

=
We can, but it won't get us anywhere. You've said that you wan= t to run your network with DHCPv6 because RAs don't suit your requireme= nts, and I'll say that I want to run my network with RAs because DHCPv6= doesn't suit my requirements. We will both have valid reasons, and pro= bably we'll even concede that in each other's networks the other= 9;s solution might be better.

But once we reach that point, we're still stuck. Be= cause the only way forward from there is to conclude that we need to define= two completely autonomous and competing systems to provision the same prot= ocol on the same host implementations, and choose one or the other dependin= g on the deployment scenario. This is a bad outcome, because hosts that wan= t to work everywhere (and what host doesn't?) need to implement both pr= otocols. The resulting complexity - which is more than 2x, because in addit= ion to the two protocols you have to define and implement rules to deal wit= h their interaction - pushes costs up for everyone, because everyone uses h= osts, including me and you.

That's why I say this is a dead horse - because the= re *is* no single technically correct answer. The community has been throug= h this exercise many times. People who want to put routing in DHCP and peop= le who don't have had arguments in several working groups, each time wi= th no conclusion, resulting in a waste of everyone's time. Let's no= t repeat that, because it isn't really in anybody's interest.

Instead, what we can do is document the semantic differ= ences and properties of the two protocols. After that, what we might be abl= e to do is get consensus on criteria for what should go into RA and into DH= CPv6 in the future. I think those are much mpre useful goals to pursue.
--047d7bf182d218333704ede59e36-- From nick@inex.ie Thu Dec 19 09:15:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB531ADF87 for ; Thu, 19 Dec 2013 09:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKUqE3sbtcTJ for ; Thu, 19 Dec 2013 09:15:28 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46D1ADDDA for ; Thu, 19 Dec 2013 09:15:27 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBJHFIRH094575 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 17:15:18 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52B329A6.1070309@inex.ie> Date: Thu, 19 Dec 2013 17:15:18 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <52B306D7.3030604@inex.ie> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:15:30 -0000 On 19/12/2013 16:25, Lorenzo Colitti wrote: > Fine, but please don't say it's simpler. It's not - it has way more moving > parts. No, actually it has a choice of moving parts and creating a priority mechanism for selecting one over the other is actually simpler than defining an interaction mechanism between the two. > We can, but it won't get us anywhere. You've said that you want to run your > network with DHCPv6 because RAs don't suit your requirements, and I'll say > that I want to run my network with RAs because DHCPv6 doesn't suit my > requirements. We will both have valid reasons, and probably we'll even > concede that in each other's networks the other's solution might be better. exactly. > But once we reach that point, we're still stuck. Because the only way > forward from there is to conclude that we need to define two completely > autonomous and competing systems to provision the same protocol on the same > host implementations, and choose one or the other depending on the > deployment scenario. yes, that is the conclusion I have come to too. And you know what? It's actually not a bad solution. > This is a bad outcome, because hosts that want to work > everywhere (and what host doesn't?) need to implement both protocols. The > resulting complexity - which is more than 2x, because in addition to the > two protocols you have to define and implement rules to deal with their > interaction - pushes costs up for everyone, because everyone uses hosts, > including me and you. at the moment we have a mess which seems to work for some people but not others, and which people have been complaining about loudly since the day that dhcp became viable. > That's why I say this is a dead horse - because there *is* no single > technically correct answer. exactly, which is why I think we need to acknowledge that it would be better for everyone to come to some conclusion to this mess. Let the people who want to use and develop SLAAC do what they want to the protocol and let the people who want to use and develop DHCPv6 do what they want. We can put in an arbitration mechanism relatively easily. I completely agree that these endless arguments are stupid. But they will continue until the heat death of the universe, or until we come to a decision to split off the two protocols - whichever comes sooner. Nick From gert@Space.Net Thu Dec 19 10:00:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAFB1AE3C1 for ; Thu, 19 Dec 2013 10:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtEE8xtO985b for ; Thu, 19 Dec 2013 10:00:05 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 69A071AE3BB for ; Thu, 19 Dec 2013 10:00:04 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 36C1964807 for ; Thu, 19 Dec 2013 19:00:02 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 00382647F2 for ; Thu, 19 Dec 2013 19:00:01 +0100 (CET) Received: (qmail 86841 invoked by uid 1007); 19 Dec 2013 19:00:01 +0100 Date: Thu, 19 Dec 2013 19:00:01 +0100 From: Gert Doering To: Nick Hilliard Message-ID: <20131219180001.GW81676@Space.Net> References: <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> <09D891E7-4305-4627-B52C-CD5D4522FD7E@nominum.com> <52B303EA.80602@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52B303EA.80602@inex.ie> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 18:00:07 -0000 Hi, On Thu, Dec 19, 2013 at 02:34:18PM +0000, Nick Hilliard wrote: > On 19/12/2013 14:21, Ted Lemon wrote: > > Also, we aren't talking about "in the home" in Nick's case. > > no, I'm talking about datacentre deployments, I wonder why one would use DHCP in the datacentre? My servers do not rely on anyone else to tell them their network config (well, actually they rely on the provisioning system, but that's "semi-static" and reboot-safe). For servers, relying on something that might not available after something unexpected, like "power outage", but which is otherwise completely unnecesarry to fulfill their role seems... surprising. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nick@inex.ie Thu Dec 19 10:08:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D29E1AE316 for ; Thu, 19 Dec 2013 10:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5zU5YhbNRjK for ; Thu, 19 Dec 2013 10:08:56 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 628641AE0E2 for ; Thu, 19 Dec 2013 10:08:56 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBJI8pqi094847 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 18:08:51 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52B33633.4090905@inex.ie> Date: Thu, 19 Dec 2013 18:08:51 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gert Doering References: <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> <09D891E7-4305-4627-B52C-CD5D4522FD7E@nominum.com> <52B303EA.80602@inex.ie> <20131219180001.GW81676@Space.Net> In-Reply-To: <20131219180001.GW81676@Space.Net> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 18:08:58 -0000 On 19/12/2013 18:00, Gert Doering wrote: > I wonder why one would use DHCP in the datacentre? ease of rollout, centralised management, etc. Tends to help when you have nontrivial numbers of vms in place. Nick From markzzzsmith@yahoo.com.au Thu Dec 19 12:19:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90C1AE776 for ; Thu, 19 Dec 2013 12:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CZo-2OLkosO for ; Thu, 19 Dec 2013 12:19:18 -0800 (PST) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with SMTP id 6DD0C1AE774 for ; Thu, 19 Dec 2013 12:19:18 -0800 (PST) Received: from [98.139.215.143] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2013 20:19:16 -0000 Received: from [98.139.212.225] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 19 Dec 2013 20:19:16 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 19 Dec 2013 20:19:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 404852.98812.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 73983 invoked by uid 60001); 19 Dec 2013 20:19:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1387484356; bh=WzLGTi4JaHBE1xCH/cBcQImybYxHTXP2W07I6URTyi8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=40czthO7e7H4EqGd0XcmkmrNHG5o2ucGRyPw+ADmiA2+EXpl66LpsJYcIqgKIqfdPz2xTYOV0BsWVTMa4gTvXZitpNzxrCts/OGcpE0055HZnrilbG3Gs36C/i3mgpOIaopZceOU8DWvcJkDywI5qLnYMQYlkF5R0SPq8WI1MSE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iOCzdBFWEFNVjLUncwXnTeiJxHgCe28W9Iks6bjSC5IWU+D3AYEZzK2CEuaOBmg+glw8QJSTDf7sHm5L0tJhHU0I76D7GTRcSd48IrEUl+LNThGpHEvBSayBWPr440JfRmt9in0ElOorYDfhnVlK2G9peASZZ4ebGQxGtI7aimY=; X-YMail-OSG: 8CavJ8cVM1mdXIpj7AgpPgIcFO0TpZ.IO2UaeUdVbM3Zacj RCk_OehKkePHaWEzNR_zbZ9F7PAxhHmeRsfuP2QBMORVWyunwTl1LDsJeoYc ygrLa_qsLKeQnMFKud2V_u7Orad_TOCUpYXnF_QPaWtBJUamTzWRZp4CfDeD 6FSj_lnbqH3NSX9QDMSlSFyp.9Z4veLRhTBkgt3GaalNCPDQFlYwt3y4BDSY 9kZYeV0u_Uf5Y5lRYMvTHu5o5NQXcZFMfUKou5wQ1Gy1Lhuj0MJLf8bBhb0i qURw3jL18PnHGr39F7XmVFAkrn2zAjNwiMkbkeJG2fqeoo0uDWaAwXICU_2h kYf47Jr86iqB2NBGvSB3MIJG1LNKdAdJrnqUV1wF3XL8QYyvj4JiiGNrdMlK mYJxh_WwBZoIos24uoIskK2FTT4ZnvkWkHZVCZjVkSNs5oqEBUfgyG8fGGsJ hneaLHaUEI4yLfH.wGMQTzqSNcazrQx5KQ2PPNWqg3i3szLXuv1WNJPKiYpN 6SSw0VAkjkhg_6X8qPq8E6nOWRhNVYuGQpl_pcYLkWaIFmzMhouvv6KTj3Yi bAB.v10HibjAvRdCD3ikdUQ-- Received: from [150.101.221.237] by web161904.mail.bf1.yahoo.com via HTTP; Thu, 19 Dec 2013 12:19:15 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGluZXguaWU.IAo.Q2M6ICJ2Nm9wc0BpZXRmLm9yZyBXRyIgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IEZyaWRheSwgMjAgRGVjZW1iZXIgMjAxMyAzOjI1IEFNCj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlvdXJ0Y2hlbmtvLXJhLWRoY3B2Ni1jb21wYXJpc28BMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <52B306D7.3030604@inex.ie> Message-ID: <1387484355.8396.YahooMailNeo@web161904.mail.bf1.yahoo.com> Date: Thu, 19 Dec 2013 12:19:15 -0800 (PST) From: Mark ZZZ Smith To: Lorenzo Colitti , Nick Hilliard In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 20:19:20 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Nick Hilliard =0A>Cc: "v6ops@iet= f.org WG" =0A>Sent: Friday, 20 December 2013 3:25 AM=0A>Su= bject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6= -comparison-00.txt (fwd)=0A> =0A>=0A>=0A>On Thu, Dec 19, 2013 at 11:46 PM, = Nick Hilliard wrote:=0A>=0A>> But what you propose is not si= mple. In fact, far from it. What you propose=0A>>> requires a DHCPv6 server= that's always up and perpetually maintains state,=0A>>> and it requires th= at you run VRRP between the routers because DHCPv6.=0A>>=0A>>Probably I'm n= ot alone in considering dhcp servers to be critical to a=0A>>functional DHC= P based network. =A0But as I said, I need DHCPv6 anyway and=A0things will b= reak if it's not available.=0A>>=0A>=0A>=0A>Fine, but please don't say it's= simpler. It's not - it has way more moving parts.=0A>=A0=0A>> If you were = designing a system from the ground up I'd wager you'd never=0A>>> design it= like that. So why do it like that, then?=0A>>=0A>>Can we stick to technica= l discussion?=0A>>=0A>=0A>=0A>We can, but it won't get us anywhere. You've = said that you want to run your network with DHCPv6 because RAs don't suit y= our requirements, and I'll say that I want to run my network with RAs becau= se DHCPv6 doesn't suit my requirements. We will both have valid reasons, an= d probably we'll even concede that in each other's networks the other's sol= ution might be better.=0A>=0A>=0A>But once we reach that point, we're still= stuck. Because the only way forward from there is to conclude that we need= to define two completely autonomous and competing systems to provision the= same protocol on the same host implementations, and choose one or the othe= r depending on the deployment scenario. This is a bad outcome, because host= s that want to work everywhere (and what host doesn't?) need to implement b= oth protocols. The resulting complexity - which is more than 2x, because in= addition to the two protocols you have to define and implement rules to de= al with their interaction - pushes costs up for everyone, because everyone = uses hosts, including me and you.=0A>=0A=0AI agree with this. Removing RAs = and replacing them with DHCPv6 from a network might appear to be reducing c= omplexity, but it is only really shifting it and creating more. Host and ro= uter implementations become more complex because they'd be expected to supp= ort both; during a transition period both methods need to be enabled and su= pported; network design decisions become more complex because a choice will= usually have to be made as to which method to support, perhaps involving a= survey of host capabilities; and troubleshooting becomes more complex beca= use there is a chance of disagreement when both RAs and DHCPv6 are run conc= urrently.=0A=0AI'd also question the criteria of "one protocol" being a goa= l. If RAs are to be shifted into DHCPv6 to achieve this goal, why isn't ND = and MLD also proposed to be moved into DHCPv6? If the problems are differen= t enough, different protocols are created. If the problems are similar enou= gh, they're solved with a single protocol.=0A=0AI consider RAs to be solvin= g the problem of link specific layer 3 configuration, and DHCPv6 to be solv= ing the problem of layer 4 and more often higher application oriented confi= guration. A very good reason (perhaps the primary?) to create two protocols= is so that one can be replaced without impacting the other (which is why I= think DNS in RAs and IPv6 addressing in DHCPv6 are mistakes). If an altern= ate application configuration protocol is developed, DHCPv6 can be replaced= without disrupting layer 3 configuration.=A0=0A=0A=0A>=0A>That's why I say= this is a dead horse - because there *is* no single technically correct an= swer. The community has been through this exercise many times. People who w= ant to put routing in DHCP and people who don't have had arguments in sever= al working groups, each time with no conclusion, resulting in a waste of ev= eryone's time. Let's not repeat that, because it isn't really in anybody's = interest.=0A>=0A>=0A>Instead, what we can do is document the semantic diffe= rences and properties of the two protocols. After that, what we might be ab= le to do is get consensus on criteria for what should go into RA and into D= HCPv6 in the future. I think those are much mpre useful goals to pursue.=0A= >=0A=0AI put some text in my "DHCPv6 option transparency" draft which I thi= nk would be useful in pursuing that goal. I described why I think the netwo= rk needs to be application configuration transparent, and therefore why a D= HCPv6 client/server in the network model reduces transparency. Further laye= r 4+ parameters in RAs have the same problem.=0A=A0=0A=0A"Internet Transpar= ency and Application Configuration"=0Ahttp://tools.ietf.org/html/draft-smit= h-v6ops-ce-dhcpv6-transparency-00#section-2=0A=0A=0ARegards,=0AMark. From simon.perreault@viagenie.ca Thu Dec 19 12:35:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89921AE7F8 for ; Thu, 19 Dec 2013 12:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0H27-mHm-Mq for ; Thu, 19 Dec 2013 12:35:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF681AE7F7 for ; Thu, 19 Dec 2013 12:35:11 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AAAD5403F7 for ; Thu, 19 Dec 2013 15:35:08 -0500 (EST) Message-ID: <52B3587C.3000900@viagenie.ca> Date: Thu, 19 Dec 2013 15:35:08 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> In-Reply-To: <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 20:35:16 -0000 Le 2013-12-11 12:52, Fred Baker (fred) a écrit : > let's take until 20 December to discuss this - WGLC. I read the draft carefully. Maybe it is because I have been involved in NAT64 since the start, but I found a lot of text to be evident or repeated from other RFCs. Anyway, I don't think this repetition is harmful, and could be useful for people new to NAT64. And there are a few new and useful nuggets. So go ahead and publish this. Minor comments inline. Simon > > > > > Internet Engineering Task Force G. Chen > Internet-Draft Z. Cao > Intended status: Informational China Mobile > Expires: June 21, 2014 C. Xie > China Telecom > D. Binet > France Telecom-Orange > December 18, 2013 > > > NAT64 Operational Experience > draft-ietf-v6ops-nat64-experience-06 > > Abstract > > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and > NAT64 server Front End (NAT64-FE) are considered in this document. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on June 21, 2014. > > Copyright Notice > > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > > > > Chen, et al. Expires June 21, 2014 [Page 1] > > Internet-Draft NAT64 Experience December 2013 > > > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4 > 3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4 > 3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4 > 3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4 > 3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5 > 3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5 > 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6 > 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 > 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 > 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 > 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 > 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 > 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 > 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 > 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 > 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 > 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 > 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 > 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 > 12. Additional Author List . . . . . . . . . . . . . . . . . . . 15 > 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 > 13.2. Informative References . . . . . . . . . . . . . . . . . 18 > Appendix A. Testing Results of Application Behavior . . . . . . 20 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 > > 1. Introduction > > IPv6 is the only sustainable solution for numbering nodes on Internet > due to the IPv4 depletion. Network operators have to deploy > IPv6-only networks in order to meet the needs of the expanding > internet without available IPv4 addresses. > > Single stack IPv6 network deployment can simplify network's s/'s// > provisioning. Some justifications have been described in 464xlat > [RFC6877]. As an example, IPv6-only connectivity confers some > benefits to mobile operators. In such mobile context, it enables the > use of a single IPv6 Packet Data Protocol(PDP) context or Evolved > Packet System (EPS) bearer if Long Term Evolution (LTE) network is > > > > Chen, et al. Expires June 21, 2014 [Page 2] > > Internet-Draft NAT64 Experience December 2013 > > > considered, which eliminates significant network costs caused by > doubling the number of PDP contexts in some cases and the need of > IPv4 addresses to be assigned to customers. In broadband networks > overall, it can allow for the scaling of edge-network growth > decoupled from IPv4 numbering limitations. > > In a transition scenario, some existing networks are likely to be > IPv4-only configured for quite a long time. IPv6 networks and hosts > will need to coexist with IPv4 numbered resources. Widespread dual- > stack deployments have not materialized at the anticipated rate over > the last 10 years, one possible conclusion being that legacy networks > will not make the jump quickly. The Internet will include nodes that > are dual-stack, nodes that remain IPv4-only, and nodes that can be > deployed as IPv6-only nodes. A translation mechanism based on a > NAT64[RFC6146] [RFC6145]function is likely to be a key element of the > Internet for IPv6-IPv4 interoperability. > > [RFC6036] reports at least 30% of operators plan to run some kind of > translator (presumably NAT64/DNS64). Advice on NAT64 deployment and > operations are therefore of some importance. [RFC6586] documents the > implications for IPv6 only networks. This document intends to be > specific to NAT64 network planning. > > 2. Terminology > > In regards to IPv4/IPv6 translation, [RFC6144] has described a > framework of enabling networks to make interworking possible between > IPv4 and IPv6 networks. This document has further categorized > different NAT64 function locations and use cases. The principle > distinction of location is if the NAT64 is located in a Carrier Grade > NAT or server Front End. The terms of NAT-CGN/FE are understood to be > a topological distinction indicating different features employed in a > NAT64 deployment. > > NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP > network. IPv6 subscribers leverage the NAT64-CGN to access > existing IPv4 internet services. The ISP as an administrative > entity takes full control on the IPv6 side, but has limited or no > control on the IPv4 side. NAT64-CGN may have to consider the IPv4 > Internet environment and services to make appropriate > configurations. > > NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device > with NAT64 functionality in a content provider or data center > network. It could be for example a traffic load balancer or a > firewall. The operator of the NAT64-FE has full control over the > IPv4 network within the data center, but only limited influence or > control over the external IPv6 network. > > > > Chen, et al. Expires June 21, 2014 [Page 3] > > Internet-Draft NAT64 Experience December 2013 > > > 3. NAT64 Networking Experience > > 3.1. NAT64-CGN Consideration > > 3.1.1. NAT64-CGN Usages > > Fixed network operators and mobile operators may locate NAT64 in > access networks or in mobile core networks. It can be built into > various devices, including routers, gateways or firewalls in order to > connect IPv6 users to the IPv4 Internet. With regard to the numbers > of users and the shortage of public IPv4 addresses, stateful > NAT64[RFC6146] is more adapted to perform some maximal sharing of > public IPv4 addresses. The usage of stateless NAT64 can be seen with > better transparency features > [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be > coordinated with A+P[RFC6346] processes as specified in > [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope [I-D.ietf-softwire-4rd] now looks very unlike stateless NAT64. I suggest removing the reference and keeping only MAP-T, which uses regular RFC6145 translation. > with IPv4 shortage. > > 3.1.2. DNS64 Deployment > > DNS64[RFC6147] is recommended for use in combination with stateful > NAT64, and will likely be an essential part of an IPv6 single-stack > network that couples to the IPv4 Internet. 464xlat[RFC6877] is > proposed to enable access of IPv4 only applications or applications > that call IPv4 literal addresses. Using DNS64 will help 464xlat to > automatically discover NAT64 prefix through [RFC7050]. Berkeley > Internet Name Daemon (BIND) software supports the function. It's > important to note that DNS64 generates the synthetic AAAA reply when > services only register A records. Operators should not expect to > access IPv4 parts of a dual-stack server using NAT64/DNS64. The > traffic is forwarded on IPv6 paths if dual-stack servers are > targeted. IPv6 traffic may be routed not going through NAT64. Only > the traffic going to IPv4-only service would traverse NAT64. In some > sense, it encourages IPv6 transmission and restrains NAT uses > compared to NAT44(if used), on which all traffic flows have to be > traversed and translated. In some cases, NAT64-CGN may serve double > roles, i.e. a translator and IPv6 forwarder. In mobile networks, > NAT64 is likely deployed as the default gateway serving for all the > IPv6 traffic. The traffic heading to a dual-stack server is only > forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested > to be configured on the Internet faced interfaces of NAT64. We > tested on Top100 websites (referring to [Alexa] statistics). 43% of > websites are connected and forwarded on the NAT64 since those > websites have both AAAA and A records. With expansion of IPv6 > supports, the translation process on NAT64 will likely be faded. > > > > > > Chen, et al. Expires June 21, 2014 [Page 4] > > Internet-Draft NAT64 Experience December 2013 > > > 3.1.3. NAT64 Placement > > All connections to IPv4 services from IPv6-only clients must traverse > the NAT64-CGN. It can be advantageous from the vantage-point of > troubleshooting and traffic engineering to carry the IPv6 traffic > natively for as long as possible within an access network and > translate packets only at or near the network egress. NAT64 can be > considered as a feature of the Autonomous System (AS) border in fixed > networks. And, it is likely to be deployed in an IP node beyond the > Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway > (PDN-GW) in mobile networks or directly in the gateway itself in some > situations. This allows consistent attribution and traceability > within the service provider network. It has been observed that the > process of correlating log information is problematic from multiple- > vendor's equipment due to inconsistent formats of log records. > Placing NAT64 in a centralized location may reduce diversity of log > format and simplify the network provisioning. Moreover, since NAT64 > is only targeted at serving traffic flows from IPv6 to IPv4-only > services, the user traffic volume should not be as high as in a NAT44 > scenario, and therefore, the gateway's capacity in such location may > not be as much of a concern or a hurdle to deployment. On the other > hand, the placement in a centralized way would require more strict > high availability (HA) design. It would also make geo-location based > on IPv4 addresses rather inaccurate as it is currently the case for > NAT44 CGN already deployed in ISP networks. More considerations or > workarounds on HA and traceability could be found at Section 4 and > Section 5. > > 3.1.4. Co-existence of NAT64 and NAT44 > > NAT64 could likely co-exist with NAT44 in a dual-stack network mostly > because IPv4 private addresses are allocated to customers. The > coexistence has already appeared in mobile networks, in which dual > stack mobile phones normally initiate some dual-stack PDN/PDP > Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated > addresses are very often private ones. [RFC6724] always prioritizes > IPv6 connections regardless of whether the end-to-end path is native > IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy > Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The > selection of IPv4/IPv6 paths may depend on particular implementation > choices or settings on a host-by-host basis, and may differ from an > operator's deterministic scheme. Our tests verified that hosts may > find themselves switching between IPv4 and IPv6 paths as they access > identical service, but at different times > [I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each > path is different, it may cause unstable user experiences and some > degradation of Quality of Experience (QoE) when fallback to the other > protocol is not powerful enough. It's also difficult for operators > > > > Chen, et al. Expires June 21, 2014 [Page 5] > > Internet-Draft NAT64 Experience December 2013 > > > to find a solution to make a stable network with optimal resource > utilization. In general, it's desirable to figure out the solution > that will introduce IPv6/IPv4 translation service to IPv6-only hosts > connecting to IPv4 servers while making sure dual-stack hosts to have > at least one address family accessible via native service if it's > possible. With the end-to-end native IPv6 environment is available, > hosts should be upgraded aggressively to migrate to IPv6-only. There > is an ongoing effort to detect host connectivity and propose new > DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate > configuration information to the hosts. > > 3.2. NAT64-FE Consideration > > Some Internet Content Providers (ICPs) may locate NAT64 in front of > an Internet Data Center (IDC), for example co-located with load > balancing function. Load balancers are employed to connect different > IP family domains, meanwhile distribute workloads across multiple > domains or internal servers actually. In some cases, IPv4 addresses > exhaustion may not be a problem in some IDC's networks. IPv6 support > for some applications may require some investments and workloads so > IPv6 support may not be a priority. The use of NAT64 may be served > to support widespread IPv6 adoption on the Internet while maintaining > IPv4-only applications access. > > Different strategy has been described in [RFC6883]referred to as > "inside out" and "outside in". An IDC operator may implement the > following practices in the NAT64-FE networking. > > o Some ICPs who already have satisfactory operational experiences > would adopt single stack IPv6 operations to build up their data > center network, servers and applications since it allows new > services delivery without having to integrate consideration of > IPv4 NAT and address limitations of IPv4 networks. Stateless > NAT64[RFC6145]is used to provide services for IPv4-only > subscribers. [I-D.anderson-siit-dc]has provided further > descriptions and guidelines. > > o ICPs who attempt to offer customers IPv6 support in their > application farms at an early stage may likely run some proxies, > which are configured to handle incoming IPv6 flows and proxy them > to IPv4 back-end systems. Many load balancers have already > integrated some proxy functionality. IPv4 addresses configured in > the proxy can be multiplexed like a stateful NAT64 performs. A > similar challenge exists once increasingly numerous users in IPv6 > Internet access an IPv4 network. High loads on load-balancers may > be apt to cause additional latency, IPv4 pool exhaustion, etc. > Therefore, this approach is only reasonable at an early stage. > ICPs may learn from the experiences and move on to dual-stack or > > > > Chen, et al. Expires June 21, 2014 [Page 6] > > Internet-Draft NAT64 Experience December 2013 > > > IPv6 single stack in a further stage, since the native IPv6 is > always more desirable than transition solutions. > > [RFC6144] recommends that AAAA records of load-balancers or > application servers can be directly registered in the authoritative > DNS servers requiring to populate these servers with corresponding > AAAA records. In this case, there is no need to deploy DNS64 > servers. Those AAAA records can be some native IPv6 addresses or > some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 > address does not give the possibility to nodes to get any information > about NAT64 presence on communication path and the possibility to > prefer IPv4 path or the IPv6 path in dual-stack networks. For the > testing purpose, operators could use an independent sub domain e.g. > ipv6exp.xxx.xxx to identify experimental ipv6 services to users. How > to design the FQDN for the IPv6 service is out-of-scope of this > document. > > 4. High Availability > > 4.1. Redundancy Design > > High Availability (HA) is a major requirement for every service and > network services. The deployment of redundancy mechanism is an > essential approach to avoid single-point failure and significantly > increase the network reliability. It's not only useful to stateful > NAT64 cases, but also to stateless NAT64 gateways. > > Three redundancy modes are mainly used hereafter: cold standby, warm > standby and hot standby. > > o Cold standby can't replicate the NAT64 states from the primary > equipment to the backup. Administrators switch on the backup > NAT64 only if the primary NAT64 fails. As the results, all the > existing established sessions will be disconnected. The internal > hosts are required to re-establish sessions to the external hosts. > Since the backup NAT64 is manually configured to switch over to > active NAT64, it may have unpredictable impacts to the ongoing > services. Normally, the handover would take several minutes so as > to wait for the whole process of NAT64 bootstrap loader. > > o Warm standby is a flavor of the cold standby mode. Backup NAT64 > would keep running once the primary NAT64 is working. This makes > warm standby less time consuming during the traffic failover. > Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a > solution to enable automatic handover in the warm standby. It was > tested that the handover takes as maximum as 1 minute if the > backup NAT64 needs to take over routing and re-construct the > Binding Information Bases (BIBs) for 30 million sessions. In > > > > Chen, et al. Expires June 21, 2014 [Page 7] > > Internet-Draft NAT64 Experience December 2013 > > > deployment phase, operators could balance loads on distinct NAT64s > devices. Those NAT64s make a warm backup of each other. > > o Hot standby must synchronize the BIBs between the primary NAT64 > and backup. When the primary NAT64 fails, backup NAT64 would take > over and maintain the state of all existing sessions. The > internal hosts don't have to re-connect the external hosts. The > handover time has been extremely reduced. Thanks to Bidirectional > Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay > of only 35ms for 30 million sessions handover was observed during > testing. In some sense, it could guarantee the session continuity > for every service. In order to timely transmit session states, > operators may have to deploy extra transport links between primary > NAT64 and distant backup. The scale of synchronization data > instance is depending on the particular deployment. For example, > If a NAT64-CGN is served for 200,000 users, the average amount of > 800, 000 sessions per second is roughly estimated for new created > and expired sessions. A 10Gbps transport link should be used for > the sync data transmission. This last recommendation needs to be qualified. There are deployments where less than 10 Gbps is plenty. > > In general, cold-standby and warm-standby is simpler and less > resource intensive, but it requires clients to re-establish sessions > when a fail-over occurs. Hot standby doubles resource's consumption "doubles" --> This can vary considerably from one implementation to another. This assertion needs to be qualified. In addition, there is at least one implementation that allows both the main and the standby to forward traffic simultaneously, approximately doubling the effective capacity when both machines are up. In that case, state synchronization is bidirectional. > to synchronize the states, but it achieve seamless handover. The > consideration of redundancy mode for stateless NAT64 is simple, > because it doesn't have to consider time consuming for states > maintenance. The warm standby is sufficient for stateless NAT64. In "Warm standby" does not apply to stateless NAT64 since there is no state synchronization. I would suggest to rephrase as: "State synchronization is unnecessary for stateless NAT64." > regards to stateful NAT64, it may be useful to investigate > performance tolerance of applications and the traffic characteristics > in a particular network. Some testing results are shown in the > Appendix A. > > Our statistics in a mobile network shown that almost 91.21% of amount > of traffic is accounted by browsing services. Those services don't > require session continuity. The handover time of warm standby is > qualified to the delay tolerance. Hot-standby does not offer much > benefit for those sessions on this point. In a fixed network, HTTP > streaming, p2p and online games would be the major > traffic[Cisco-VNI]. Consideration should be given to the importance > of maintaining bindings for those sessions across failover. > Operators may also consider the Average Revenue Per User (ARPU) > factors to deploy suitable redundancy mode. Warm standby may still > be adopted to cover most services while hot standby could be used to > upgrade Quality of Experience (QoE) using DNS64 with different > synthetic responses for limited traffic. Further considerations are > discussed at Section 6. > > > > > > Chen, et al. Expires June 21, 2014 [Page 8] > > Internet-Draft NAT64 Experience December 2013 > > > 4.2. Load Balancing > > Load balancing is used to accompany redundancy design so that better > scalability and resiliency could be achieved. Stateless NAT64s allow > asymmetric routing while anycast-based solutions are recommended in > [I-D.ietf-softwire-map-deployment]. The deployment of load balancing > may make more sense to stateful NAT64s for the sake of single-point > failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct > facilities, the following lists the considerations for each case. > > o NAT64-CGN equipment doesn't implement load balancer functions on a > board card. Therefore, the gateways have to resort to DNS64 or > internal host's behavior. Once DNS64 is deployed, the load > balancing can be performed by synthesizing AAAA response with > different IPv6 prefixes. For the applications not requiring DNS > resolver, internal hosts could learn multiple IPv6 prefixes > through the approaches defined in[RFC7050] and then select one > based on a given prefix selection policy. There is at least one implementation that allows both the main and the standby to forward traffic simultaneously, with bidirectional state synchronization. (I don't know if one can build a farm of >2 such machines.) This is one form of load balancing that should be mentioned here. > o A dedicated Load Balancer could be deployed at front of a NAT64-FE > farm. Load Balancer uses proxy mode to redirect the flows to the > appropriate NAT64 instance. Stateful NAT64s require a > deterministic pattern to arrange the traffic in order to ensure > outbound/inbound flows traverse the identical NAT64. Therefore, > static scheduling algorithms, for example source-address based > policy, is preferred. A dynamic algorithm, for example Round- > Robin, may have impacts on applications seeking session > continuity, which described in the Table 1. I doubt that this is a valid load balancing method. For a fixed amount of traffic, it is less work to apply NAT64 than to apply load balancing. That's all! 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 tore@fud.no Thu Dec 19 12:51:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8D1AE1E2 for ; Thu, 19 Dec 2013 12:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PFzc2KYsaKh for ; Thu, 19 Dec 2013 12:51:05 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id C3A9B1AE1AF for ; Thu, 19 Dec 2013 12:51:05 -0800 (PST) Received: from [2a02:fe0:c410:1d30:21d:60ff:fe48:f59e] (port=47529 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.80) (envelope-from ) id 1VtkYf-0006Bk-Up; Thu, 19 Dec 2013 21:51:01 +0100 Message-ID: <52B35C35.3040808@fud.no> Date: Thu, 19 Dec 2013 21:51:01 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nick Hilliard , Gert Doering References: <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com> <09D891E7-4305-4627-B52C-CD5D4522FD7E@nominum.com> <52B303EA.80602@inex.ie> <20131219180001.GW81676@Space.Net> <52B33633.4090905@inex.ie> In-Reply-To: <52B33633.4090905@inex.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 20:51:07 -0000 * Nick Hilliard > On 19/12/2013 18:00, Gert Doering wrote: >> I wonder why one would use DHCP in the datacentre? > > ease of rollout, centralised management, etc. Tends to help when you have > nontrivial numbers of vms in place. Indeed. We use DHCP extensively in our data centres. Provisioning OS onto the servers we do with network boot. This is much more convenient than physical media or, worse, remote media (which usually depends on some Java hocus pocus that works correctly only during an eclipse and so on), and mindlessly clicking through an install wizard N times. One variant of the above that we've grown more and more fond of in recent years is to have stateless servers without disks that *always* boot off the network. They install the OS onto a RAM disk, registers with Puppet and installs whatever applications they need and are ready to go within minutes. This is especially nice for running applications that can automatically scale horizontally onto whatever compute resources are available. Think for example hypervisors, HPC nodes, and such. An application needs more capacity? No problem: plug in a dozen servers, turn them on, and they're all up and running, in production, within 15 minutes with no human interaction necessary beyond the physical part. It's a wonderful way to work, tbh, and it all relies 100% on DHCP. Unfortunately, it's all DHCP*v4*. Hardly any server manufacturer is shipping units that can do IPv6 network booting, it's the 3Com PXE ROM from, what, 2001? they're all shipping still. This is perhaps the largest impediment to IPv6 deployment I'm dealing with on a day-to-day basis. Getting improvement here would be way more valuable to IPv6 deployment than continued bickering of whether it is RA or DHCPv6 that is the dog's bollocks.... Tore From brian.e.carpenter@gmail.com Thu Dec 19 13:21:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A5E1AE907 for ; Thu, 19 Dec 2013 13:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stWqxFFXo9mB for ; Thu, 19 Dec 2013 13:21:09 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A445D1AE20E for ; Thu, 19 Dec 2013 13:21:09 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id rq2so1681882pbb.30 for ; Thu, 19 Dec 2013 13:21:07 -0800 (PST) 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=nln/ACiU+pCeIj/mo9O7wqJzHpTOt98mQle74wcemR0=; b=cxrMbv2WA8/obfKXKwxAnGW9NJcpiCjuhdGctgDp/VY/YXTqCPcdhW017gexrGxZzg /q29n+StPMpZYHMEe5BsDfRDzPS26jU8C/1Yq3Pg8wGR4WbcCGTfCaiasgiQMjBJkA0/ xQ6+HNbApmjlngA3Xi76AO80HT+Spj3IHwFOcg5Bt4BQbBd3+MehSmbJtiQOma2qzkXV THCr4qKJIotxRDDEcVsNZz1pQm4PEElqiEH8l+5Ad9TrDOveKKWoPYZMIPCAbvnEDNxq OhmgAJ3vvm8xnaYKnkN2v5NqHvswwVjwCyjtaLQIKOAs76ER7yJgHK+lOo2CZTSAskk5 yaAA== X-Received: by 10.66.66.234 with SMTP id i10mr4083037pat.127.1387488067846; Thu, 19 Dec 2013 13:21:07 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id by1sm9482091pbd.25.2013.12.19.13.21.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Dec 2013 13:21:06 -0800 (PST) Message-ID: <52B36349.6090901@gmail.com> Date: Fri, 20 Dec 2013 10:21:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <52B306D7.3030604@inex.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 21:21:11 -0000 On 20/12/2013 05:25, Lorenzo Colitti wrote: ... > Instead, what we can do is document the semantic differences and properties > of the two protocols. After that, what we might be able to do is get > consensus on criteria for what should go into RA and into DHCPv6 in the > future. I think those are much mpre useful goals to pursue. This is exactly what we need the document under discussion to do. No opinions, no judgments - just document the facts. Somebody can draw the Venn diagram afterwards, and then (and only then) we can tackle the question of what the Venn diagram *should* be. Brian From nick@inex.ie Thu Dec 19 14:03:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8CB1AEA35 for ; Thu, 19 Dec 2013 14:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEhlojhrmyae for ; Thu, 19 Dec 2013 14:03:23 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 764B81AEA3C for ; Thu, 19 Dec 2013 14:03:22 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rBJM3Hp6096362 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 22:03:17 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52B36D25.603@inex.ie> Date: Thu, 19 Dec 2013 22:03:17 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark ZZZ Smith References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <52B306D7.3030604@inex.ie> <1387484355.8396.YahooMailNeo@web161904.mail.bf1.yahoo.com> In-Reply-To: <1387484355.8396.YahooMailNeo@web161904.mail.bf1.yahoo.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 22:03:26 -0000 On 19/12/2013 20:19, Mark ZZZ Smith wrote: > I agree with this. Removing RAs and replacing them with DHCPv6 from a > network might appear to be reducing complexity, but it is only really > shifting it and creating more. Host and router implementations become > more complex because they'd be expected to support both; during a > transition period both methods need to be enabled and supported; network > design decisions become more complex because a choice will usually have > to be made as to which method to support, perhaps involving a survey of > host capabilities; and troubleshooting becomes more complex because > there is a chance of disagreement when both RAs and DHCPv6 are run > concurrently. Yes, it shifts some complexity, reduces a pile more in the long term, but doesn't create a significant quantity of new complexity because it's not that difficult to create an arbitration mechanism to handle how things should be handled on the host side. The state diagram for this is not very large, tbh. Have you drawn it out? > I'd also question the criteria of "one protocol" being a goal. If RAs > are to be shifted into DHCPv6 to achieve this goal, why isn't ND and MLD > also proposed to be moved into DHCPv6? This is a straw man argument and a rather poor one. ND is concerned with l3 address to mac layer address mapping and is a separate problem domain. I don't know why you think that MLD is similar enough in function to DHCP that you're mentioning them in the same sentence as potential candidates for functionality merging. RAs and dhcpv6 are both concerned with host auto-configuration. We have a single protocol in ipv4 which provides a superset of the equivalent functionality of dhcpv6 and enough of the functionality of RAs to reliably provide network connectivity and many people consider this a good thing. Also... > If the problems are different > enough, different protocols are created. If the problems are similar > enough, they're solved with a single protocol. ... this is my point: DHCPv6 is exactly two options away from being independent of RAs to the point that it would be entirely usable in many situations. This is because problem domains are substantially the same, as indicated by the fact that dhcpv4 covers all one, the intersection between the two and a chunk of what RAs add. > I consider RAs to be solving the problem of link specific layer 3 > configuration, and DHCPv6 to be solving the problem of layer 4 and more > often higher application oriented configuration. And I consider having two protocols to handle the job of one to be poor quality protocol design, regardless of the best intentions of the people who designed it like this. Now we have a deployment / operational mess on our hands which people have been complaining about for years and will continue to complain about until it's fixed. Maybe you don't consider it to be a mess, but I do and a lot of other people do - people who have complained loudly about it over the years and whose positions were, well, ignored. Whether you like it or not, it is a problem which will not go away by pretending it doesn't exist. > A very good reason > (perhaps the primary?) to create two protocols is so that one can be > replaced without impacting the other (which is why I think DNS in RAs > and IPv6 addressing in DHCPv6 are mistakes). If an alternate application > configuration protocol is developed, DHCPv6 can be replaced without > disrupting layer 3 configuration. This is actually a complete non-argument. Nick From owen@delong.com Thu Dec 19 15:32:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F4F1AEC53 for ; Thu, 19 Dec 2013 15:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_24=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7f0fs7JF8eJ for ; Thu, 19 Dec 2013 15:32:58 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EE7241AEC50 for ; Thu, 19 Dec 2013 15:32:57 -0800 (PST) Received: from kiwi.he.net (kiwi.he.net [IPv6:2001:470:0:a9:fc85:28af:970e:6eeb] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id rBJNSiqL017825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Dec 2013 15:28:45 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com rBJNSiqL017825 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1387495726; bh=iuMuoquXH51vUnckVWyEgLeFVLM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wDWa2mXdSV57X8sM9zbf0E7YV1EPk8UYy3v8bk6sjBSjqP8pOWMDSz2+WquJ8Fec6 xKVUQCq55ZwPMQTVgxzpYrgZlhNmnQ4fSYIUyr3gL85Y0GE2x5mltCFpnJS3Z1zSyX jWnkkv/nj4HaOzZcVmSjt6Z0cAfPUUF8xEdNFaWo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Owen DeLong In-Reply-To: <52B2ED1E.1040108@inex.ie> Date: Thu, 19 Dec 2013 15:28:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1502B710-CAEE-470B-8C16-18D632776ED6@delong.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1822) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 19 Dec 2013 15:28:46 -0800 (PST) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 23:32:59 -0000 > I'm just stating that for my deployment scenarios, I specifically do = not > want the extra stuff that RAs/SLAAC provide like load-balancing over > multiple routers, deprecation of defgws, multiple networks/gateways = per l2 > domain and all that. >=20 > On the other hand, I need to run DHCPv6 because RAs do not provide me = with > the technical knobs that I need. These include address assignment = (rather > than slaac), and other dhcp-only knobs. >=20 > In this context, RAs serve only to provide defgw and (as Tore kindly > reminded me) prefix assignment, and then hand everything off to = DHCPv6. >=20 > Leaving aside the operational issues associated with running separate > configuration on separate systems for the same end goal of > autoconfiguration, from a protocol simplicity point of view, this = approach > is not very sensible because, we have an entire protocol dedicated to > handling something that with a modest amount of effort could probably = be > handled by dhcpv6. First, auto configuration is not really one end goal. There are elements = of auto configuration which are host-specific (system) configuration and elements which are network topology (routing) configuration.=20 Host-specific configuration includes DNS Resolvers, NTP servers, Boot file servers, boot file names, Host DNS information (DDNS), and more. Network topology information includes default gateway, other more = specific routes, routing metrics, and more. Addresses themselves are kind of the merge point of these two aspects of configuration and that=92s one of the reasons that addresses themselves = may be assigned by SLAAC, DHCPv6, or possibly both in some scenarios. Additionally, RA/RS and SLAAC are not a separate protocol unto = themselves. They are specific messages within the Neighbor Discovery Protocol which also includes NA/NS messages. Are you also arguing that you want your DHCP server to provide the IP->MAC address translation table? If not, = then you aren=92t able to turn off the entire protocol that RS/RA are part of = anyway and the horse is basically dead. > I'm sorry you feel this is a dead horse. My take is that if we're > designing a protocol which has an expected lifetime of $manyyears, = then > protocol simplicity should be high on the list. Given the amount of = recent > noise on this list discussing the interaction between RA+DHCP, it's > abundantly clear that simplicity has been lost in favour of confusion. I think most of the confusion is not so much because simplicity is lost, = but, because people are arguing about how they think things should be done = instead of listening to each other about how they are actually done. As I have said, I favor adding the extensions you want to DHCP, but, I = do think it is somewhat fool hearty to use them and I do not advocate making = RS/RA optional parts of the neighbor discovery process. In fact, I think = routers should, by default, emit useful RS/RA messages and it should take configuration = effort to turn them off. On a host, it should also take configuration effort to = get the host not to send RS messages. Further, I=92m not sure how you propose = for a host which knows nothing to know that it needs to ask for DHCP = information without first getting an RA that says so. I really don=92t favor the = complexity of =93Ask for configuration from every possible mechanism and see what = sticks=94. That would make things much more complicated than the current scenario. > Simplicity is a critically important design goal for anything related = to > engineering, and the old maxim is true: "everything should be kept as > simple as possible, but no simpler=94. For the flexibility provided, I believe that the current protocol design = actually provides a high degree of simplicity. However, it definitely needs to be = better documented and much less ambiguously specified. It really would be = helpful if this group would focus on achieving that before trying to make a = bunch of changes to it. > If possible, I'd really like if we could have a non-heated discussion = about > the technical pros and cons of whether standalone DHCPv6 is viable. I don=92t think my comments have been at all heated and I think = Lorenzo=92s were pretty measured as well. However, while I think standalone DHCPv6 could = be made viable, I do not think it would aid in your stated goal of protocol = simplicity, nor do I believe that it would be beneficial in any way. > I know that for my use cases, it would be a highly desirable endpoint, = but > I understand that other people have different deployment requirements. Correct me if I=92m wrong, but you have to configure at least one router = on every subnet in your deployment with an IPv6 address and prefix length. Is it really that hard to add the one line that gives you the M-bit? After that, everything else goes in DHCPv6 where you want it. Where=92s the unnecessary complexity? The host knows it needs to grab an = RA when it wakes up to find out about what to do next. When it gets the = M-bit, it knows it needs to do DHCP and it does that. The router tells the host = about things that the router knows best and the DHCP server tells the host about the = things the DHCP server knows best. This seems much simpler than having to tell = the DHCP server every time you change the address of a router or replace a = router or=85 Owen From phdgang@gmail.com Thu Dec 19 22:01:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2AE1AF620 for ; Thu, 19 Dec 2013 22:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujPhUNnrM20K for ; Thu, 19 Dec 2013 22:01:21 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE341AF65E for ; Thu, 19 Dec 2013 22:01:21 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id w5so5593398qac.6 for ; Thu, 19 Dec 2013 22:01:19 -0800 (PST) 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=CdyRZEXoS+ad4mkxLIDQGz3+0M8S0XkmCv8MqpoesA0=; b=swUwOR8vgRCQWznlBg+/5AVDSSxTFZ/Yf5XesXspUIt0UULssK6ueSMXLuIcMPpMeK c9kJ63yRpkUa1Ux+7jnmz74wrbNXLPluQZP2TdclRpzc1qIpLpIeUr86TW+6e6wcZdxQ 4q9LnxFAAvmW64y45s+VTs5mJdn50/tjvTP4Tg/L8OVXLz0yA9YQ3rIEwAqIqlmATQ4n d/7rhkuNR07uJp5v59yP3/5wSf5TUUCN/BkQnj1YucMBrFKE1ysd2RU6itNBWffVoetS 3UncVW+Gj+Nm1qsY0Nkpm7exq2OwsBMhvDxsTI/GWcKSn8KjDOWVL92lP3Li7T1W2oFP 5h0w== MIME-Version: 1.0 X-Received: by 10.49.116.5 with SMTP id js5mr10602160qeb.36.1387519279064; Thu, 19 Dec 2013 22:01:19 -0800 (PST) Received: by 10.224.44.12 with HTTP; Thu, 19 Dec 2013 22:01:18 -0800 (PST) In-Reply-To: <52B3587C.3000900@viagenie.ca> References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> <52B3587C.3000900@viagenie.ca> Date: Fri, 20 Dec 2013 14:01:18 +0800 Message-ID: From: GangChen To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 06:01:26 -0000 2013/12/20, Simon Perreault : > Le 2013-12-11 12:52, Fred Baker (fred) a =E9crit : >> let's take until 20 December to discuss this - WGLC. > > I read the draft carefully. Maybe it is because I have been involved in > NAT64 since the start, but I found a lot of text to be evident or > repeated from other RFCs. Anyway, I don't think this repetition is > harmful, and could be useful for people new to NAT64. And there are a > few new and useful nuggets. So go ahead and publish this. > > Minor comments inline. Thank you for the comments and review. Please see my reply inline. > Simon > >> >> >> >> >> Internet Engineering Task Force G. Chen >> Internet-Draft Z. Cao >> Intended status: Informational China Mobile >> Expires: June 21, 2014 C. Xie >> China Telecom >> D. Binet >> France Telecom-Orange >> December 18, 2013 >> >> >> NAT64 Operational Experience >> draft-ietf-v6ops-nat64-experience-06 >> >> Abstract >> >> This document summarizes NAT64 function deployment scenarios and >> operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and >> NAT64 server Front End (NAT64-FE) are considered in this document. >> >> Status of This Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on June 21, 2014. >> >> Copyright Notice >> >> Copyright (c) 2013 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 1] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4 >> 3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4 >> 3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4 >> 3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4 >> 3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5 >> 3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5 >> 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6 >> 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 >> 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 >> 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 >> 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 >> 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 >> 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 >> 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 >> 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 >> 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 >> 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 >> 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 >> 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 >> 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 >> 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 >> 12. Additional Author List . . . . . . . . . . . . . . . . . . . 15 >> 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 >> 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 >> 13.2. Informative References . . . . . . . . . . . . . . . . . 18 >> Appendix A. Testing Results of Application Behavior . . . . . . 20 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 >> >> 1. Introduction >> >> IPv6 is the only sustainable solution for numbering nodes on Internet >> due to the IPv4 depletion. Network operators have to deploy >> IPv6-only networks in order to meet the needs of the expanding >> internet without available IPv4 addresses. >> >> Single stack IPv6 network deployment can simplify network's > > s/'s// > >> provisioning. Some justifications have been described in 464xlat >> [RFC6877]. As an example, IPv6-only connectivity confers some >> benefits to mobile operators. In such mobile context, it enables the >> use of a single IPv6 Packet Data Protocol(PDP) context or Evolved >> Packet System (EPS) bearer if Long Term Evolution (LTE) network is >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 2] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> considered, which eliminates significant network costs caused by >> doubling the number of PDP contexts in some cases and the need of >> IPv4 addresses to be assigned to customers. In broadband networks >> overall, it can allow for the scaling of edge-network growth >> decoupled from IPv4 numbering limitations. >> >> In a transition scenario, some existing networks are likely to be >> IPv4-only configured for quite a long time. IPv6 networks and hosts >> will need to coexist with IPv4 numbered resources. Widespread dual- >> stack deployments have not materialized at the anticipated rate over >> the last 10 years, one possible conclusion being that legacy networks >> will not make the jump quickly. The Internet will include nodes that >> are dual-stack, nodes that remain IPv4-only, and nodes that can be >> deployed as IPv6-only nodes. A translation mechanism based on a >> NAT64[RFC6146] [RFC6145]function is likely to be a key element of the >> Internet for IPv6-IPv4 interoperability. >> >> [RFC6036] reports at least 30% of operators plan to run some kind of >> translator (presumably NAT64/DNS64). Advice on NAT64 deployment and >> operations are therefore of some importance. [RFC6586] documents the >> implications for IPv6 only networks. This document intends to be >> specific to NAT64 network planning. >> >> 2. Terminology >> >> In regards to IPv4/IPv6 translation, [RFC6144] has described a >> framework of enabling networks to make interworking possible between >> IPv4 and IPv6 networks. This document has further categorized >> different NAT64 function locations and use cases. The principle >> distinction of location is if the NAT64 is located in a Carrier Grade >> NAT or server Front End. The terms of NAT-CGN/FE are understood to be >> a topological distinction indicating different features employed in a >> NAT64 deployment. >> >> NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP >> network. IPv6 subscribers leverage the NAT64-CGN to access >> existing IPv4 internet services. The ISP as an administrative >> entity takes full control on the IPv6 side, but has limited or no >> control on the IPv4 side. NAT64-CGN may have to consider the IPv4 >> Internet environment and services to make appropriate >> configurations. >> >> NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device >> with NAT64 functionality in a content provider or data center >> network. It could be for example a traffic load balancer or a >> firewall. The operator of the NAT64-FE has full control over the >> IPv4 network within the data center, but only limited influence or >> control over the external IPv6 network. >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 3] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> 3. NAT64 Networking Experience >> >> 3.1. NAT64-CGN Consideration >> >> 3.1.1. NAT64-CGN Usages >> >> Fixed network operators and mobile operators may locate NAT64 in >> access networks or in mobile core networks. It can be built into >> various devices, including routers, gateways or firewalls in order to >> connect IPv6 users to the IPv4 Internet. With regard to the numbers >> of users and the shortage of public IPv4 addresses, stateful >> NAT64[RFC6146] is more adapted to perform some maximal sharing of >> public IPv4 addresses. The usage of stateless NAT64 can be seen with >> better transparency features >> [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be >> coordinated with A+P[RFC6346] processes as specified in >> [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope > > [I-D.ietf-softwire-4rd] now looks very unlike stateless NAT64. I suggest > removing the reference and keeping only MAP-T, which uses regular > RFC6145 translation. > >> with IPv4 shortage. >> >> 3.1.2. DNS64 Deployment >> >> DNS64[RFC6147] is recommended for use in combination with stateful >> NAT64, and will likely be an essential part of an IPv6 single-stack >> network that couples to the IPv4 Internet. 464xlat[RFC6877] is >> proposed to enable access of IPv4 only applications or applications >> that call IPv4 literal addresses. Using DNS64 will help 464xlat to >> automatically discover NAT64 prefix through [RFC7050]. Berkeley >> Internet Name Daemon (BIND) software supports the function. It's >> important to note that DNS64 generates the synthetic AAAA reply when >> services only register A records. Operators should not expect to >> access IPv4 parts of a dual-stack server using NAT64/DNS64. The >> traffic is forwarded on IPv6 paths if dual-stack servers are >> targeted. IPv6 traffic may be routed not going through NAT64. Only >> the traffic going to IPv4-only service would traverse NAT64. In some >> sense, it encourages IPv6 transmission and restrains NAT uses >> compared to NAT44(if used), on which all traffic flows have to be >> traversed and translated. In some cases, NAT64-CGN may serve double >> roles, i.e. a translator and IPv6 forwarder. In mobile networks, >> NAT64 is likely deployed as the default gateway serving for all the >> IPv6 traffic. The traffic heading to a dual-stack server is only >> forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested >> to be configured on the Internet faced interfaces of NAT64. We >> tested on Top100 websites (referring to [Alexa] statistics). 43% of >> websites are connected and forwarded on the NAT64 since those >> websites have both AAAA and A records. With expansion of IPv6 >> supports, the translation process on NAT64 will likely be faded. >> >> >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 4] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> 3.1.3. NAT64 Placement >> >> All connections to IPv4 services from IPv6-only clients must traverse >> the NAT64-CGN. It can be advantageous from the vantage-point of >> troubleshooting and traffic engineering to carry the IPv6 traffic >> natively for as long as possible within an access network and >> translate packets only at or near the network egress. NAT64 can be >> considered as a feature of the Autonomous System (AS) border in fixed >> networks. And, it is likely to be deployed in an IP node beyond the >> Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway >> (PDN-GW) in mobile networks or directly in the gateway itself in some >> situations. This allows consistent attribution and traceability >> within the service provider network. It has been observed that the >> process of correlating log information is problematic from multiple- >> vendor's equipment due to inconsistent formats of log records. >> Placing NAT64 in a centralized location may reduce diversity of log >> format and simplify the network provisioning. Moreover, since NAT64 >> is only targeted at serving traffic flows from IPv6 to IPv4-only >> services, the user traffic volume should not be as high as in a NAT44 >> scenario, and therefore, the gateway's capacity in such location may >> not be as much of a concern or a hurdle to deployment. On the other >> hand, the placement in a centralized way would require more strict >> high availability (HA) design. It would also make geo-location based >> on IPv4 addresses rather inaccurate as it is currently the case for >> NAT44 CGN already deployed in ISP networks. More considerations or >> workarounds on HA and traceability could be found at Section 4 and >> Section 5. >> >> 3.1.4. Co-existence of NAT64 and NAT44 >> >> NAT64 could likely co-exist with NAT44 in a dual-stack network mostly >> because IPv4 private addresses are allocated to customers. The >> coexistence has already appeared in mobile networks, in which dual >> stack mobile phones normally initiate some dual-stack PDN/PDP >> Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated >> addresses are very often private ones. [RFC6724] always prioritizes >> IPv6 connections regardless of whether the end-to-end path is native >> IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy >> Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The >> selection of IPv4/IPv6 paths may depend on particular implementation >> choices or settings on a host-by-host basis, and may differ from an >> operator's deterministic scheme. Our tests verified that hosts may >> find themselves switching between IPv4 and IPv6 paths as they access >> identical service, but at different times >> [I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each >> path is different, it may cause unstable user experiences and some >> degradation of Quality of Experience (QoE) when fallback to the other >> protocol is not powerful enough. It's also difficult for operators >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 5] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> to find a solution to make a stable network with optimal resource >> utilization. In general, it's desirable to figure out the solution >> that will introduce IPv6/IPv4 translation service to IPv6-only hosts >> connecting to IPv4 servers while making sure dual-stack hosts to have >> at least one address family accessible via native service if it's >> possible. With the end-to-end native IPv6 environment is available, >> hosts should be upgraded aggressively to migrate to IPv6-only. There >> is an ongoing effort to detect host connectivity and propose new >> DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate >> configuration information to the hosts. >> >> 3.2. NAT64-FE Consideration >> >> Some Internet Content Providers (ICPs) may locate NAT64 in front of >> an Internet Data Center (IDC), for example co-located with load >> balancing function. Load balancers are employed to connect different >> IP family domains, meanwhile distribute workloads across multiple >> domains or internal servers actually. In some cases, IPv4 addresses >> exhaustion may not be a problem in some IDC's networks. IPv6 support >> for some applications may require some investments and workloads so >> IPv6 support may not be a priority. The use of NAT64 may be served >> to support widespread IPv6 adoption on the Internet while maintaining >> IPv4-only applications access. >> >> Different strategy has been described in [RFC6883]referred to as >> "inside out" and "outside in". An IDC operator may implement the >> following practices in the NAT64-FE networking. >> >> o Some ICPs who already have satisfactory operational experiences >> would adopt single stack IPv6 operations to build up their data >> center network, servers and applications since it allows new >> services delivery without having to integrate consideration of >> IPv4 NAT and address limitations of IPv4 networks. Stateless >> NAT64[RFC6145]is used to provide services for IPv4-only >> subscribers. [I-D.anderson-siit-dc]has provided further >> descriptions and guidelines. >> >> o ICPs who attempt to offer customers IPv6 support in their >> application farms at an early stage may likely run some proxies, >> which are configured to handle incoming IPv6 flows and proxy them >> to IPv4 back-end systems. Many load balancers have already >> integrated some proxy functionality. IPv4 addresses configured in >> the proxy can be multiplexed like a stateful NAT64 performs. A >> similar challenge exists once increasingly numerous users in IPv6 >> Internet access an IPv4 network. High loads on load-balancers may >> be apt to cause additional latency, IPv4 pool exhaustion, etc. >> Therefore, this approach is only reasonable at an early stage. >> ICPs may learn from the experiences and move on to dual-stack or >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 6] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> IPv6 single stack in a further stage, since the native IPv6 is >> always more desirable than transition solutions. >> >> [RFC6144] recommends that AAAA records of load-balancers or >> application servers can be directly registered in the authoritative >> DNS servers requiring to populate these servers with corresponding >> AAAA records. In this case, there is no need to deploy DNS64 >> servers. Those AAAA records can be some native IPv6 addresses or >> some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 >> address does not give the possibility to nodes to get any information >> about NAT64 presence on communication path and the possibility to >> prefer IPv4 path or the IPv6 path in dual-stack networks. For the >> testing purpose, operators could use an independent sub domain e.g. >> ipv6exp.xxx.xxx to identify experimental ipv6 services to users. How >> to design the FQDN for the IPv6 service is out-of-scope of this >> document. >> >> 4. High Availability >> >> 4.1. Redundancy Design >> >> High Availability (HA) is a major requirement for every service and >> network services. The deployment of redundancy mechanism is an >> essential approach to avoid single-point failure and significantly >> increase the network reliability. It's not only useful to stateful >> NAT64 cases, but also to stateless NAT64 gateways. >> >> Three redundancy modes are mainly used hereafter: cold standby, warm >> standby and hot standby. >> >> o Cold standby can't replicate the NAT64 states from the primary >> equipment to the backup. Administrators switch on the backup >> NAT64 only if the primary NAT64 fails. As the results, all the >> existing established sessions will be disconnected. The internal >> hosts are required to re-establish sessions to the external hosts. >> Since the backup NAT64 is manually configured to switch over to >> active NAT64, it may have unpredictable impacts to the ongoing >> services. Normally, the handover would take several minutes so as >> to wait for the whole process of NAT64 bootstrap loader. >> >> o Warm standby is a flavor of the cold standby mode. Backup NAT64 >> would keep running once the primary NAT64 is working. This makes >> warm standby less time consuming during the traffic failover. >> Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a >> solution to enable automatic handover in the warm standby. It was >> tested that the handover takes as maximum as 1 minute if the >> backup NAT64 needs to take over routing and re-construct the >> Binding Information Bases (BIBs) for 30 million sessions. In >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 7] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> deployment phase, operators could balance loads on distinct NAT64s >> devices. Those NAT64s make a warm backup of each other. >> >> o Hot standby must synchronize the BIBs between the primary NAT64 >> and backup. When the primary NAT64 fails, backup NAT64 would take >> over and maintain the state of all existing sessions. The >> internal hosts don't have to re-connect the external hosts. The >> handover time has been extremely reduced. Thanks to Bidirectional >> Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay >> of only 35ms for 30 million sessions handover was observed during >> testing. In some sense, it could guarantee the session continuity >> for every service. In order to timely transmit session states, >> operators may have to deploy extra transport links between primary >> NAT64 and distant backup. The scale of synchronization data >> instance is depending on the particular deployment. For example, >> If a NAT64-CGN is served for 200,000 users, the average amount of >> 800, 000 sessions per second is roughly estimated for new created >> and expired sessions. A 10Gbps transport link should be used for >> the sync data transmission. > > This last recommendation needs to be qualified. There are deployments > where less than 10 Gbps is plenty. 10Gbps is evaluated considering the amount of session at the peak and link capacity redundancy during the deployment. The transmitted amount of sync session at the peak is testified as around 1.3Gbps. If the redundancy ratio of 0.5 is considered, the transport link should have around 2.6Gpbs capacity. However, a physical transport link only has very specific capacity, for example 10Gbps, 2.5Gbps, 155M Therefore, 10Gbps may have to be selected as the physical transport link capacity. We could qualify the statement by adding specific conditions OLD =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A 10Gbps transport link should be used for the sync data transmission. NEW =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A physical 10Gbps transport link may have to be deployed for the sync data transmission considering the amount of sync sessions at the peak and link capacity redundancy. >> >> In general, cold-standby and warm-standby is simpler and less >> resource intensive, but it requires clients to re-establish sessions >> when a fail-over occurs. Hot standby doubles resource's consumption > > "doubles" --> This can vary considerably from one implementation to > another. This assertion needs to be qualified. "doubles" is evaluated because the mapping state should be stored at both the primary and backup equipment. As you point out, that is depending on the implementation. we could change the sentence as =3D=3DNEW Hot standby increases resource's consumption > In addition, there is at least one implementation that allows both the > main and the standby to forward traffic simultaneously, approximately > doubling the effective capacity when both machines are up. In that case, > state synchronization is bidirectional. That will be mentioned at load balance section as below. >> to synchronize the states, but it achieve seamless handover. The >> consideration of redundancy mode for stateless NAT64 is simple, >> because it doesn't have to consider time consuming for states >> maintenance. The warm standby is sufficient for stateless NAT64. In > > "Warm standby" does not apply to stateless NAT64 since there is no state > synchronization. I would suggest to rephrase as: "State synchronization > is unnecessary for stateless NAT64." There is a mistake. I will correct the statement as you suggested. >> regards to stateful NAT64, it may be useful to investigate >> performance tolerance of applications and the traffic characteristics >> in a particular network. Some testing results are shown in the >> Appendix A. >> >> Our statistics in a mobile network shown that almost 91.21% of amount >> of traffic is accounted by browsing services. Those services don't >> require session continuity. The handover time of warm standby is >> qualified to the delay tolerance. Hot-standby does not offer much >> benefit for those sessions on this point. In a fixed network, HTTP >> streaming, p2p and online games would be the major >> traffic[Cisco-VNI]. Consideration should be given to the importance >> of maintaining bindings for those sessions across failover. >> Operators may also consider the Average Revenue Per User (ARPU) >> factors to deploy suitable redundancy mode. Warm standby may still >> be adopted to cover most services while hot standby could be used to >> upgrade Quality of Experience (QoE) using DNS64 with different >> synthetic responses for limited traffic. Further considerations are >> discussed at Section 6. >> >> >> >> >> >> Chen, et al. Expires June 21, 2014 [Page 8] >> =0C >> Internet-Draft NAT64 Experience December 2013 >> >> >> 4.2. Load Balancing >> >> Load balancing is used to accompany redundancy design so that better >> scalability and resiliency could be achieved. Stateless NAT64s allow >> asymmetric routing while anycast-based solutions are recommended in >> [I-D.ietf-softwire-map-deployment]. The deployment of load balancing >> may make more sense to stateful NAT64s for the sake of single-point >> failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct >> facilities, the following lists the considerations for each case. >> >> o NAT64-CGN equipment doesn't implement load balancer functions on a >> board card. Therefore, the gateways have to resort to DNS64 or >> internal host's behavior. Once DNS64 is deployed, the load >> balancing can be performed by synthesizing AAAA response with >> different IPv6 prefixes. For the applications not requiring DNS >> resolver, internal hosts could learn multiple IPv6 prefixes >> through the approaches defined in[RFC7050] and then select one >> based on a given prefix selection policy. > > There is at least one implementation that allows both the main and the > standby to forward traffic simultaneously, with bidirectional state > synchronization. (I don't know if one can build a farm of >2 such > machines.) This is one form of load balancing that should be mentioned > here. The changes are o NAT64-CGN could balance loads on the primary and the backup equipment= . Those NAT64s may make bidirectional state synchronization for each ot= her. The load balance can also resort to DNS64 or internal host's behavior. Once DNS64 is deployed, the load balancing can be performed by synthesizing AAAA response with different IPv6 prefixes. For the applications not requiring DNS resolver, internal hosts could learn multiple IPv6 prefixes through the approaches defined in[RFC7050] and then select one based on a given prefix selection policy. =09 > >> o A dedicated Load Balancer could be deployed at front of a NAT64-FE >> farm. Load Balancer uses proxy mode to redirect the flows to the >> appropriate NAT64 instance. Stateful NAT64s require a >> deterministic pattern to arrange the traffic in order to ensure >> outbound/inbound flows traverse the identical NAT64. Therefore, >> static scheduling algorithms, for example source-address based >> policy, is preferred. A dynamic algorithm, for example Round- >> Robin, may have impacts on applications seeking session >> continuity, which described in the Table 1. > > I doubt that this is a valid load balancing method. For a fixed amount > of traffic, it is less work to apply NAT64 than to apply load balancing. That is a common practice in a data center because a load balancer is normally deployed. Load balancer could distribute the traffic to different NAT64 according to the configured scheduling algorithms. So we just document it as is. BRs Gang > That's all! > > 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From simon.perreault@viagenie.ca Fri Dec 20 05:35:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634161ADBCC for ; Fri, 20 Dec 2013 05:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrvk4y59uD6j for ; Fri, 20 Dec 2013 05:35:40 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB90D1ACC88 for ; Fri, 20 Dec 2013 05:35:40 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 54D86403AF; Fri, 20 Dec 2013 08:35:38 -0500 (EST) Message-ID: <52B447AA.7080805@viagenie.ca> Date: Fri, 20 Dec 2013 08:35:38 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: GangChen References: <20131209033734.26917.18115.idtracker@ietfa.amsl.com> <39690BB5-A194-4C11-B6EE-9EE51B46F966@cisco.com> <52B3587C.3000900@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 13:35:42 -0000 Le 2013-12-20 01:01, GangChen a écrit : > Thank you for the comments and review. Please see my reply inline. Thanks. I'm OK with the proposed changes. 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 sthaug@nethelp.no Fri Dec 20 05:42:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBA41AC85E for ; Fri, 20 Dec 2013 05:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlb5fab4bmVd for ; Fri, 20 Dec 2013 05:42:28 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id C33381AD8F4 for ; Fri, 20 Dec 2013 05:42:25 -0800 (PST) Received: (qmail 68426 invoked from network); 20 Dec 2013 13:42:18 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 20 Dec 2013 13:42:18 -0000 Date: Fri, 20 Dec 2013 14:42:18 +0100 (CET) Message-Id: <20131220.144218.71144704.sthaug@nethelp.no> To: owen@delong.com From: sthaug@nethelp.no In-Reply-To: <1502B710-CAEE-470B-8C16-18D632776ED6@delong.com> References: <52B2ED1E.1040108@inex.ie> <1502B710-CAEE-470B-8C16-18D632776ED6@delong.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 13:42:30 -0000 > Additionally, RA/RS and SLAAC are not a separate protocol unto themselves. > They are specific messages within the Neighbor Discovery Protocol which > also includes NA/NS messages. Are you also arguing that you want your > DHCP server to provide the IP->MAC address translation table? If not, then > you aren’t able to turn off the entire protocol that RS/RA are part of anyway > and the horse is basically dead. Speaking only for myself - I want the ND part of the protocol to be used by default. I absolutely do *not* want routers to send RA by default. (I do not want the DHCP server to deal with the IP->MAC address translation table.) At least one router manufacturer (Juniper) has made the operationally useful choice (to me, at least) of having ND turned on by default when an interface is configured with an IPv6 address, while RA must be turned on by explicit configuration. Thank you Juniper! And the horse is not dead yet... Steinar Haug, AS 2116 From Fred.L.Templin@boeing.com Fri Dec 20 08:29:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD37A1A1F1B for ; Fri, 20 Dec 2013 08:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8vxixhrET6d for ; Fri, 20 Dec 2013 08:29:49 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 65D701A1F66 for ; Fri, 20 Dec 2013 08:29:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id rBKGTlfn005114; Fri, 20 Dec 2013 08:29:47 -0800 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rBKGTepo004943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 20 Dec 2013 08:29:40 -0800 Received: from XCH-EXCO-105.nw.nos.boeing.com (130.247.204.69) by XCH-PHX-510.sw.nos.boeing.com (10.57.37.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 08:29:40 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.203]) by XCH-EXCO-105.nw.nos.boeing.com ([169.254.1.18]) with mapi id 14.03.0158.001; Fri, 20 Dec 2013 10:29:39 -0600 From: "Templin, Fred L" To: Owen DeLong , Nick Hilliard Thread-Topic: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) Thread-Index: AQHO/RK2R1TuU55iZEKvsHtEA9l5RJpdRhPQ Date: Fri, 20 Dec 2013 16:29:38 +0000 Message-ID: <2134F8430051B64F815C691A62D98318181C13@XCH-BLV-504.nw.nos.boeing.com> References: <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <52B22828.6080700@inex.ie> <52B2ED1E.1040108@inex.ie> <1502B710-CAEE-470B-8C16-18D632776ED6@delong.com> In-Reply-To: <1502B710-CAEE-470B-8C16-18D632776ED6@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 16:29:50 -0000 > Where's the unnecessary complexity? The host knows it needs to grab an RA > when it wakes up to find out about what to do next. When it gets the M-bi= t, it > knows it needs to do DHCP and it does that. The router tells the host abo= ut things > that the router knows best and the DHCP server tells the host about the t= hings > the DHCP server knows best. This seems much simpler than having to tell t= he > DHCP server every time you change the address of a router or replace a ro= uter > or... I agree with that, plus the DHCP server may be far away from the link in some backhaul network where it has more global knowledge while the router is on the link where it may have only localized knowledge. Let DHCP servers do what DHCP servers do, and let routers do what routers do. Fred fred.l.templin@boeing.com From internet-drafts@ietf.org Sun Dec 22 18:12:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ECA1AE3DC; Sun, 22 Dec 2013 18:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wotuw9cDz91O; Sun, 22 Dec 2013 18:12:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6EA1AE42E; Sun, 22 Dec 2013 18:12:42 -0800 (PST) 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 X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131223021242.30083.72457.idtracker@ietfa.amsl.com> Date: Sun, 22 Dec 2013 18:12:42 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 02:12:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experience Authors : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-07.txt Pages : 22 Date : 2013-12-22 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fred@cisco.com Wed Dec 25 05:45:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800251ADF5C for ; Wed, 25 Dec 2013 05:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.039 X-Spam-Level: X-Spam-Status: No, score=-115.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReW93ilBlq51 for ; Wed, 25 Dec 2013 05:45:18 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 123511ADF4D for ; Wed, 25 Dec 2013 05:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139; q=dns/txt; s=iport; t=1387979114; x=1389188714; h=date:from:message-id:to:subject:cc; bh=h64uAv8eBZUX+meQGyQn1r1CDxYaEbRd+ZCV69pCa94=; b=SUF+L0R2zUAHuI+shEF0wOAyLXPSN/uNlmGjvX3s378LlLSKKLiig+F4 8tEIxDcVtW1UoygFT4W8WcFWEMwLW/25wRJNX8YVr06TTuFI9BVPMqjol pS8bFULPESh+/2kyizfPN8vtkUzb/EG7kE5MLrwYRLKtwkZIgQ8KUfHPN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYJACTgulKrRDoJ/2dsb2JhbABYgws4qAQBkj0DBAKBGBZ0gyU8LQeIZA7JDhePHR2EIASJQ5AEkGSDTg X-IronPort-AV: E=Sophos;i="4.95,548,1384300800"; d="scan'208";a="98902714" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 25 Dec 2013 13:45:12 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBPDj1Vd019220; Wed, 25 Dec 2013 13:45:08 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id rBPDj1u26004; Wed, 25 Dec 2013 05:45:01 -0800 (PST) Date: Wed, 25 Dec 2013 05:45:01 -0800 (PST) From: Message-Id: <201312251345.rBPDj1u26004@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-liu-v6ops-dhcpv6-slaac-guidance@tools.ietf.org Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 13:45:19 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Please take a look at it and comment. From markzzzsmith@yahoo.com.au Thu Dec 26 23:22:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473251AEE0E for ; Thu, 26 Dec 2013 23:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEdKP1oAQx2X for ; Thu, 26 Dec 2013 23:22:35 -0800 (PST) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with SMTP id D0FFA1AEDFE for ; Thu, 26 Dec 2013 23:22:34 -0800 (PST) Received: from [66.196.81.173] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 27 Dec 2013 07:22:30 -0000 Received: from [98.139.212.235] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 27 Dec 2013 07:22:30 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 27 Dec 2013 07:22:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 106915.2601.bm@omp1044.mail.bf1.yahoo.com Received: (qmail 90794 invoked by uid 60001); 27 Dec 2013 07:22:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1388128949; bh=3IAjATdo3dP2E7H66EIzciY3IF9/HFdw9zaF68P+foU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2kt4CaZN0K4mUOD6A6uTiXEjskbYsSPHZw4knRy6iEl2NDiif04WnrI0fyaSNiRDRSv5xp31MqUWRWMWB3x2iN7f4wH/lO3+Gd3h3252cQ9CC9/GzzUt8YRAuToJfSmfdPeyK9/BS3ihAwfUvibipaZ5M0+Yw82LcMd+LzlT+W8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LsAMvaIKJN+3+Ne4GttiMSZXyeJdt0ffLH71hi3NPxQwjMxF1uCYQmUUEwUJdlC+6dgNOG8tgGSpl6YZSAn+55CWce0IPDYTQcLmSokMUGCawUYXdw23GyeKRBmDo0IV2Zpf4gGDZGBaHujCwb0X/NT4lvkUm4pePsyo9ewxYlo=; X-YMail-OSG: QuxY8GAVM1nXGF7ycbItMwek4VoXqZn6i3_6J68dZsnGepI lmxfbUi3sCL7Ctc1szkCJCnAjyG4.5cc25lWMi18jkdnlXu_YNopOShVoX5U Pd6rOR0fTKofyzVFTcfWMNaX4LUYzmcyfjR0.ocLlhuAqpfN1o1Kifag1fjI cUzb2r_McBMRYKgnEBUY6ri0wv2zbn9yjM_mEenFqyR5UCSF2L.HTGtxwTNa jeUKeYAgJUdNoF6vDloL70Zew1iFOeET9pUA9T6Pzpb8snTV0.9raEyELQA3 Teke8oa7slmsoRgJ0gZ.3Rz1e6bCF8jUdcSHAbFRjws0E9MpBVHdRC6jLFbi 11QCWULYnI9nfMNTyAE77C8LFQgs3SEkBdvTKE508UOyPJz5hkurbJvo6vvP PSKzJ3mC5YSDhE7v3y.Wi90ClBkYTYiJEIKX.2eiX1md0EOJuzuA9iigp0Un 3PO2g803NHz2N55CZ0UF9Ntn5ocCQPUIl6KqLZdt5rVs9g1IXsspo.3iMO8G 2If54oGa.4fdgnP1gB842vc4510WMcXSk_FdAq5UHrqE.x9bflXcUrZcu3ii 8CSbrmuoMCBmVZqBByIo- Received: from [150.101.221.237] by web161905.mail.bf1.yahoo.com via HTTP; Thu, 26 Dec 2013 23:22:29 PST X-Rocket-MIMEInfo: 002.001, SGksCgpJJ3ZlIGhhZCBhIGJyaWVmIGxvb2ssIEknZCBzdGlsbCBsaWtlIHRvIHNlZSBzb21lIGV2aWRlbmNlIHRoYXQgd2hhdCBpcyBkZXNjcmliZWQgaGFzIGFjdHVhbGx5IGJlZW4gZWZmZWN0aXZlLiBBcyBoYXMgYmVlbiBtZW50aW9uZWQsIHRoZXJlIGFyZSBhIG51bWJlciBvZiByZWFzb25zIHdoeSBTd2lzc2NvbSdzIGN1c3RvbWVycyBoYXZlIG5vdCBzdWZmZXJlZCBmcm9tIGF0dGFja3MsIHN1Y2ggYXMgdWJpcXVpdG91cyBwZXItaG9zdCBmaXJld2FsbHMsIElQdjYncyBsYXJnZSBhZGRyZXNzIHNwYWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> Message-ID: <1388128949.79987.YahooMailNeo@web161905.mail.bf1.yahoo.com> Date: Thu, 26 Dec 2013 23:22:29 -0800 (PST) From: Mark ZZZ Smith To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" In-Reply-To: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 07:22:37 -0000 Hi,=0A=0AI've had a brief look, I'd still like to see some evidence that wh= at is described has actually been effective. As has been mentioned, there a= re a number of reasons why Swisscom's customers have not suffered from atta= cks, such as ubiquitous per-host firewalls, IPv6's large address space or I= Pv6 temporary addresses. If there was no measurement before this method was= deployed and then no measurement afterwards, it isn't possible to assert t= hat this method is effective and the reason for lack of attacks.=0A=0AI thi= nk it should be fairly easy to produce evidence that the ports that are blo= cked in this draft are actively being attacked - ACLs match counters with p= ermit statements on Swisscom's BRASes/BNGs with permit statements for the s= pecific ports that are blocked would be evidence.=0A=0AI don't think the ds= hield port report is evidence, as it doesn't report IPv4 and IPv6 separatel= y, meaning that the report could be all IPv4 data, or that the IPv6 ports a= re only to obvious unsolicited addresses such as ::1, and therefore the att= empted attack is less likely to be effective anyway with EUI-64 based IIDs = or the future stable and opaque IIDs.=0A=0ARegards,=0AMark.=0A=0A=0A=0A=0A-= ---- Original Message -----=0A> From: "internet-drafts@ietf.org" =0A> To: i-d-announce@ietf.org=0A> Cc: v6ops@ietf.org=0A> S= ent: Saturday, 7 December 2013 2:38 AM=0A> Subject: [v6ops] I-D Action: dra= ft-ietf-v6ops-balanced-ipv6-security-01.txt=0A> =0A> =0A> A New Internet-Dr= aft is available from the on-line Internet-Drafts directories.=0A> This dra= ft is a work item of the IPv6 Operations Working Group of the IETF.=0A> =0A= > =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Balanced Security for IPv6 Resident= ial CPE=0A> =A0=A0=A0 Author(s)=A0 =A0 =A0 : Martin Gysi=0A> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Guillaume Leclanche=0A> =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Vyncke=0A> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ragnar Anfinsen=0A> =A0=A0=A0 Filename= =A0 =A0 =A0 =A0 : draft-ietf-v6ops-balanced-ipv6-security-01.txt=0A> =A0=A0= =A0 Pages=A0 =A0 =A0 =A0 =A0 : 9=0A> =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0= : 2013-12-06=0A> =0A> Abstract:=0A> =A0 This document describes how an IP= v6 residential Customer Premise=0A> =A0 Equipment (CPE) can have a balance= d security policy that allows for a=0A> =A0 mostly end-to-end connectivity= while keeping the major threats=0A> =A0 outside of the home.=A0 It is doc= umenting an existing IPv6 deployment=0A> =A0 by Swisscom and allows all pa= ckets inbound/outbound EXCEPT for some=0A> =A0 layer-4 ports where attacks= and vulnerabilities (such as weak=0A> =A0 passwords) are well-known.=A0 T= he policy is a proposed set of rules=0A> =A0 that can be used as a default= setting.=A0 The set of blocked inbound=0A> =A0 and outbound ports is expe= cted to be updated as threats come and go.=0A> =0A> =0A> The IETF datatrack= er status page for this draft is:=0A> https://datatracker.ietf.org/doc/draf= t-ietf-v6ops-balanced-ipv6-security=0A> =0A> There's also a htmlized versio= n available at:=0A> http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ip= v6-security-01=0A> =0A> A diff from the previous version is available at:= =0A> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-balanced-ipv6-secu= rity-01=0A> =0A> =0A> Please note that it may take a couple of minutes from= the time of submission=0A> until the htmlized version and diff are availab= le at tools.ietf.org.=0A> =0A> Internet-Drafts are also available by anonym= ous FTP at:=0A> ftp://ftp.ietf.org/internet-drafts/=0A> =0A> ______________= _________________________________=0A> v6ops mailing list=0A> v6ops@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Fri Dec 27 00:33:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11321AEFA0 for ; Fri, 27 Dec 2013 00:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.171 X-Spam-Level: * X-Spam-Status: No, score=1.171 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHU0e4t9-pUy for ; Fri, 27 Dec 2013 00:33:35 -0800 (PST) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) by ietfa.amsl.com (Postfix) with ESMTP id 100DF1AEF9F for ; Fri, 27 Dec 2013 00:33:34 -0800 (PST) Received: from [98.139.212.152] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 27 Dec 2013 08:33:30 -0000 Received: from [98.139.212.246] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 27 Dec 2013 08:33:30 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 27 Dec 2013 08:33:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 354974.63907.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 94946 invoked by uid 60001); 27 Dec 2013 08:33:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1388133210; bh=KkWy/z2dctLdKyGKLjvT6B12U40Tb8tRPi+B+aaskMs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RLTsjZYkDN1Ggp749G2n0VL4SmZERtBSzGtlGp9AYzD+JF8PRlEjBcXea592XHnQLDbJ/9AyDqcLRHIMjNbZvXd3uzVsuMYG6nDRvtWOHpJMSvksiPi8k5Y9BH1vbx6VNGFE+ZkP7r3+Z9BB7lzJOMjpb2dkab2p8HpXm6VQZMs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lrZ/60OL0Ipx+AXfUASEGF9VX+c3BOmkUGbCZiu4u7d0ExygOUWPDhW4zZ2yT9W1cegVSaxjWMj8AYfAmX6IdG6pjdA9MGuwzvI/eiFtwOcG4APTYeRIzODcZbDQ8jQJqW80ZW8mdjXKT0GdvV9OGVxv+ArvG6Ca8qiXMIphafQ=; X-YMail-OSG: gz76krIVM1neozk6jmDQueWXccNPrYej_qeCsN0eyd0opUg KjqEa3MKpqlS_._Vl2fCvjsPvRVEqrl1gll_GkbBcrLhyxLXz8dSa8m6OCUo iBhr_lgaICdh3nYgKCjf3.r5UcwSBPwiwKcrVffZycEPGl3kKm4vic0k9oqD PsdL3GDcQwp0AmxJmrSZcF5ckkFzGqQViYV9FHtL9AqhAD1d18_DZXfICFjc FcWT7SHYk7KaIi.csee0iw52.xopbQHTIjbLkJBR6CpFWa8pUmg6tsftCIXl 2CxF01fLNfn2ybKyxcbLId9g8O_qzr.vo5kLCDF5g7LbuH0M7_f7BbYAg8v0 UoeWWYUfw6nHuzkECmw.qBjdXo_Rz9mgAbKhh0wb.iKlcDsLl48pkIYBdOhW JCxCRNmcogFc9RUc4s5vqD4le1dPpi9GGrOydw_VCsSKAVYZTXlToFonNn7c i6tn.5A42ngMefCJhiiJYVWbQs1zK506.4ACKtwBA7SOCF4voSSspEPaPf5k N9o6Zru2XiSy6xsECE7pQ8i3gcw0HQ7XmQ4TeXm9.nehjsEIf_Ejf8q0qt7a 4EZBDWEPDy4EpEBAQSpMi Received: from [150.101.221.237] by web161904.mail.bf1.yahoo.com via HTTP; Fri, 27 Dec 2013 00:33:30 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBUbzogImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz47ICJpLWQtYW5ub3VuY2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc.Cj4gQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPgo.IFNlbnQ6IEZyaWRheSwgMjcgRGVjZW1iZXIgMjAxMyA2OjIyIFBNCj4gU3ViamVjdDogUmU6IFsBMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 References: <20131206153834.19120.52021.idtracker@ietfa.amsl.com> <1388128949.79987.YahooMailNeo@web161905.mail.bf1.yahoo.com> Message-ID: <1388133210.81918.YahooMailNeo@web161904.mail.bf1.yahoo.com> Date: Fri, 27 Dec 2013 00:33:30 -0800 (PST) From: Mark ZZZ Smith To: Mark ZZZ Smith , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" In-Reply-To: <1388128949.79987.YahooMailNeo@web161905.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 08:33:37 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mark ZZZ Smith =0A> To: "internet-drafts@ietf.org" ; "i-d-announce@ietf.org" =0A> Cc: "v6ops@ietf.= org" =0A> Sent: Friday, 27 December 2013 6:22 PM=0A> Subjec= t: Re: [v6ops] I-D Action:=09draft-ietf-v6ops-balanced-ipv6-security-01.txt= =0A> =0A> Hi,=0A> =0A> I've had a brief look, I'd still like to see some ev= idence that what is =0A> described has actually been effective. As has been= mentioned, there are a number =0A> of reasons why Swisscom's customers hav= e not suffered from attacks, such as=A0=0A=0Ashould have been "customers ma= y not have".=0A=0A=0A> ubiquitous per-host firewalls, IPv6's large address = space or IPv6 temporary =0A> addresses. If there was no measurement before = this method was deployed and then =0A> no measurement afterwards, it isn't = possible to assert that this method is =0A> effective and the reason for la= ck of attacks.=0A> =0A> I think it should be fairly easy to produce evidenc= e that the ports that are =0A> blocked in this draft are actively being att= acked - ACLs match counters with =0A> permit statements on Swisscom's BRASe= s/BNGs with permit statements for the =0A> specific ports that are blocked = would be evidence.=0A> =0A> I don't think the dshield port report is eviden= ce, as it doesn't report =0A> IPv4 and IPv6 separately, meaning that the re= port could be all IPv4 data, or =0A> that the IPv6 ports are only to obviou= s unsolicited addresses such as ::1, and =0A> therefore the attempted attac= k is less likely to be effective anyway with EUI-64 =0A> based IIDs or the = future stable and opaque IIDs.=0A> =0A> Regards,=0A> Mark.=0A> =0A>